Skip site navigation (1) Skip section navigation (2)

Re: CommitFest 2009-09, two weeks on

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>, Dan Colish <dan(at)unencrypted(dot)org>
Subject: Re: CommitFest 2009-09, two weeks on
Date: 2009-10-01 19:05:55
Message-ID: 4AC4FD93.9000804@cybertec.at (view raw or flat)
Thread:
Lists: 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 in the 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/


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-10-01 19:17:03
Subject: Re: "make install" now tries to build the documentation
Previous:From: Tom LaneDate: 2009-10-01 18:55:18
Subject: Re: FSM search modes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group