Re: Split-up ECPG patches

Michael Meskes írta:
> On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
>
>> as asked by Michael Meskes, I have split up our ECPG patchset:
>>
>
> Just a couple quick comments.
>
> It appears to me (without much testing) that the patches still partly rely on
> each other. But I cannot see a reason for this.
>

There are three reasons:

1. sqlda and string type support both add one constant in ecptypes.h
2. dynamic cursorname and DESCRIBE support both modify the
FetchStmt rule.
3. DESCRIBE support partially builds on sqlda support

I saw no point creating patches that are applicable standalone
when they would conflict each other. The point would be to have
all patches upstreamed, reviewed and applied in the order
indicated by the patch filenames.

Another point was that where to split features?
SQLDA and DESCRIBE [OUTPUT] features overlap.

>> 1. dynamic cursorname (DECLARE :cursorname ..., etc)
>> 2. SQLDA support in Informix compat mode (C structure used for
>> descriptor and data query)
>>
>
> One file has this:
>
> * (C) 2009 Cybertec GmbH
> * Zolt??n B??sz??rm??nyi <zb(at)cybertec(dot)at>
> * Hans-J??rgen Sch??nig <hs(at)cybertec(dot)at>
>
> Shouldn't this also list a license? In general I wonder whether we need some
> statement for every patch submitted? Anyone more into licensing might comment
> here.
>

What is the correct way to indicate that the licence is the same
as the PostgreSQL licence but we are the authors? We aren't
license experts. :-)

>> 3. DESCRIBE OUTPUT support for named and sqlda descriptors
>>
>
> I don't think we have to add ECPGdescribe2 to keep the old API. The old
> ECPGdescribe function does nothing, so it's not worth being kept.
>

I thought about easing transition and letting old binaries work as is.
IIRC a common wisdom is that if you add API calls, you only need to
increase the minor library version. But if you modify an existing
call you create an incompatibility (even when the usage of said call
was unlikely) and the major library version need to be increased.

>> 4. "string" pseudo-type in Informix compat mode
>>
>
> There is still a lot of stuff being done when not in compatibility mode. I
> thought you wanted to change that?
>

The things is that in Informix mode, the patch refuses
"typedef ... string;", in native mode it lets "string"
typename through. "make check" under ecpg passes. Isn't that
enough? Is there a particular place you didn't like?

Thanks for the review so far.

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/