Re: CommitFest 2009-09, two weeks on - Mailing list pgsql-hackers

Michael Meskes írta:
> On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
>   
>> Please, accept my apologies, I only tried to express my
>> frustration, this is not a good situation for either of us.
>>     
>
> Apologies accepted, email is a difficult means of communication anyway. It
> leads to misunderstanding IMO.
>
>   
>> You were busy with your job and other occupations.
>> We have a serious project going on that depend on
>> ECPG being more compatible to Informix.
>>     
>
> Please keep in mind that the needs of your business project cannot and will not
> influence the way PostgreSQL as on OSS project will work.
>   

Yes, but technical problems and solutions do. ECPG claims
to be ESQL/C compatible, but at places it's only half compatible.
For our project to succeed, we need more compatibility in ECPG.
It's easier to solve these problems in ECPG than to code around it
in literally thousands of little programs.

BTW, a thought about the comment in ecpg.header about adjust_informix():
       /* Informix accepts DECLARE with variables that are out of scope
when OPEN is called.        * for instance you can declare variables in a function, and
then subsequently use them        * {        *      declare_vars();        *      exec sql ... which uses vars declared
inthe above function        *        * This breaks standard and leads to some very dangerous
 
programming.

This comment is misleading and reflects quite a narrow POV.
Not only OPEN and DECLARE may be out of scope,
but FETCH and CLOSE as well. The reason why ESQL/C
allows this construct is that this ultimately allows using
embedded SQL in event-driven code in a straightforward way.
For this purpose, native ECPG code is not usable currently,
or you need programming tricks, like tracking whether the
cursor is open and protecting DECLARE and OPEN under
some conditional branch to avoid double open, etc. A straight
DECLARE, OPEN, FETCH(s) and CLOSE series in
the same function is only good for batch programming.

>> Would this be accepted this way? Or the two modification washed into one?
>>     
>
> It is accepted either way. I was just pointing out that it might be easier to
> review/commit at least parts of your patches if they can be applied seperately.
>   

Okay, I will split the remaining patches into more little pieces
that can reviewed more easily. Some patches will still build
on earlier ones in the series, that's unavoidable.

>> I thought you forgot that patch, the "please, look at that patch"
>> was an (I thought) polite request, it's really two one-liners.
>>     
>
> Well, this is true as the patch was buried in the long thread containing all
> the other ones. And yes, now that you brought it into my memory again, I
> already committed it. Sorry for missing it.
>   

Thank you very much for committing it.

Best regards,
Zoltán Böszörményi

-- 
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/