Thread: ECPG enhancements / fixes
Hi Michael,
I have been on holiday for three weeks and spent a part of the evenings
with my computer. So here are a couple of patches against 3 weeks ago's
CVS. If these patches are too outdated and you would like me to generate
a patch against current sources, please drop me a note. Since I have
been out of reach for any TCP/IP packet, I'm totally unaware of recent
changes ;-)
(Apply the patches in order to avoid conflicts)
0. This patch allows empty function calls in variable initializations.
This is really common for C++ code (e.g. string::c_str() ) and we had to
put nearly 50% of all initializations outside the declare section
because of this unnecessary limitation.
1. This patch implements 'cardinality' of descriptors (number of rows is
a result)
2. This patch implements support for arrays for storing results ('data',
'indicator') via get descriptor. (without this functionaly #1 is only of
informative value).
3. This bigger patch implements support for host variables containing
the descriptor name in all descriptor related commands.
4. This patch implements 'execute STATEMENT [using :VAR] into :VAR'.
Clearly a nice thing to have (understatement, it hurts badly to have
not).
5. This patch implements the syntax for 'execute into descriptor' and
'select into descriptor'. Making descriptors really neat. This patch
makes no sense without #6.
6. This patch implements the library support for #5. Actually
descriptors become like a special kind of host variables.
7. This patch cleans up the code duplication created by the first
descriptor implementation. And renders the old public library function
for descriptor results 'ECPGdo_descriptor' to unnecessary compatibility
code.
I have the patches separated into small pieces, so they can be
viewed/applied separately - but I see no reason of omitting any of them.
And please (if possible) could #0 and #4 also get applied to STABLE
(7.1)?
My opinion is that the functionality implemented by these patches is so
basic that they would justify dumping the 7.2 tree of ecpg into the
STABLE tree even if this means that ecpg accepts syntact constructs not
accepted by the 7.1 backend (because they are implemented in 7.2).
Considering an ecpg which lacks most of the functionality of the SQL
standard as stable is nonsense IMHO.
(Oh sorry, no offense meant to you, since you are the maintainer, I just
wanted to explain the status quo to people not so familiar to ecpg's
development.)
Yours
Christof
PS: On my to do list:
- implementing array allocation by 'get descriptor' ( by taking the code
out of ECPGexecute into a new function which copies _one_ column of a
result into _one_ variable) This would allow 'get descriptor' and
'ECPGexecute' to share code again.
- implementing host variables for cursor names, table names etc. Since
these things require a different quoting (" instead of ') a new Variable
type / flag is necessary.
- writing a new documentation which covers recent ecpg development (last
two years :-( )
Perhaps later on I might find some time / interest to implement the
following: (next year?)
- set descriptor / using descriptor : this functionality is covered by
snprintf.
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Hi Michael,
>
> I have been on holiday for three weeks and spent a part of the evenings
> with my computer. So here are a couple of patches against 3 weeks ago's
> CVS. If these patches are too outdated and you would like me to generate
> a patch against current sources, please drop me a note. Since I have
> been out of reach for any TCP/IP packet, I'm totally unaware of recent
> changes ;-)
>
> (Apply the patches in order to avoid conflicts)
>
> 0. This patch allows empty function calls in variable initializations.
> This is really common for C++ code (e.g. string::c_str() ) and we had to
> put nearly 50% of all initializations outside the declare section
> because of this unnecessary limitation.
>
> 1. This patch implements 'cardinality' of descriptors (number of rows is
> a result)
>
> 2. This patch implements support for arrays for storing results ('data',
> 'indicator') via get descriptor. (without this functionaly #1 is only of
> informative value).
>
> 3. This bigger patch implements support for host variables containing
> the descriptor name in all descriptor related commands.
>
> 4. This patch implements 'execute STATEMENT [using :VAR] into :VAR'.
> Clearly a nice thing to have (understatement, it hurts badly to have
> not).
>
> 5. This patch implements the syntax for 'execute into descriptor' and
> 'select into descriptor'. Making descriptors really neat. This patch
> makes no sense without #6.
>
> 6. This patch implements the library support for #5. Actually
> descriptors become like a special kind of host variables.
>
> 7. This patch cleans up the code duplication created by the first
> descriptor implementation. And renders the old public library function
> for descriptor results 'ECPGdo_descriptor' to unnecessary compatibility
> code.
>
>
> I have the patches separated into small pieces, so they can be
> viewed/applied separately - but I see no reason of omitting any of them.
> And please (if possible) could #0 and #4 also get applied to STABLE
> (7.1)?
>
> My opinion is that the functionality implemented by these patches is so
> basic that they would justify dumping the 7.2 tree of ecpg into the
> STABLE tree even if this means that ecpg accepts syntact constructs not
> accepted by the 7.1 backend (because they are implemented in 7.2).
> Considering an ecpg which lacks most of the functionality of the SQL
> standard as stable is nonsense IMHO.
> (Oh sorry, no offense meant to you, since you are the maintainer, I just
> wanted to explain the status quo to people not so familiar to ecpg's
> development.)
>
> Yours
> Christof
>
> PS: On my to do list:
> - implementing array allocation by 'get descriptor' ( by taking the code
> out of ECPGexecute into a new function which copies _one_ column of a
> result into _one_ variable) This would allow 'get descriptor' and
> 'ECPGexecute' to share code again.
>
> - implementing host variables for cursor names, table names etc. Since
> these things require a different quoting (" instead of ') a new Variable
> type / flag is necessary.
>
> - writing a new documentation which covers recent ecpg development (last
> two years :-( )
>
> Perhaps later on I might find some time / interest to implement the
> following: (next year?)
> - set descriptor / using descriptor : this functionality is covered by
> snprintf.
>
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
It appears Michael has already applied this. Thanks.
> Hi Michael,
>
> I have been on holiday for three weeks and spent a part of the evenings
> with my computer. So here are a couple of patches against 3 weeks ago's
> CVS. If these patches are too outdated and you would like me to generate
> a patch against current sources, please drop me a note. Since I have
> been out of reach for any TCP/IP packet, I'm totally unaware of recent
> changes ;-)
>
> (Apply the patches in order to avoid conflicts)
>
> 0. This patch allows empty function calls in variable initializations.
> This is really common for C++ code (e.g. string::c_str() ) and we had to
> put nearly 50% of all initializations outside the declare section
> because of this unnecessary limitation.
>
> 1. This patch implements 'cardinality' of descriptors (number of rows is
> a result)
>
> 2. This patch implements support for arrays for storing results ('data',
> 'indicator') via get descriptor. (without this functionaly #1 is only of
> informative value).
>
> 3. This bigger patch implements support for host variables containing
> the descriptor name in all descriptor related commands.
>
> 4. This patch implements 'execute STATEMENT [using :VAR] into :VAR'.
> Clearly a nice thing to have (understatement, it hurts badly to have
> not).
>
> 5. This patch implements the syntax for 'execute into descriptor' and
> 'select into descriptor'. Making descriptors really neat. This patch
> makes no sense without #6.
>
> 6. This patch implements the library support for #5. Actually
> descriptors become like a special kind of host variables.
>
> 7. This patch cleans up the code duplication created by the first
> descriptor implementation. And renders the old public library function
> for descriptor results 'ECPGdo_descriptor' to unnecessary compatibility
> code.
>
>
> I have the patches separated into small pieces, so they can be
> viewed/applied separately - but I see no reason of omitting any of them.
> And please (if possible) could #0 and #4 also get applied to STABLE
> (7.1)?
>
> My opinion is that the functionality implemented by these patches is so
> basic that they would justify dumping the 7.2 tree of ecpg into the
> STABLE tree even if this means that ecpg accepts syntact constructs not
> accepted by the 7.1 backend (because they are implemented in 7.2).
> Considering an ecpg which lacks most of the functionality of the SQL
> standard as stable is nonsense IMHO.
> (Oh sorry, no offense meant to you, since you are the maintainer, I just
> wanted to explain the status quo to people not so familiar to ecpg's
> development.)
>
> Yours
> Christof
>
> PS: On my to do list:
> - implementing array allocation by 'get descriptor' ( by taking the code
> out of ECPGexecute into a new function which copies _one_ column of a
> result into _one_ variable) This would allow 'get descriptor' and
> 'ECPGexecute' to share code again.
>
> - implementing host variables for cursor names, table names etc. Since
> these things require a different quoting (" instead of ') a new Variable
> type / flag is necessary.
>
> - writing a new documentation which covers recent ecpg development (last
> two years :-( )
>
> Perhaps later on I might find some time / interest to implement the
> following: (next year?)
> - set descriptor / using descriptor : this functionality is covered by
> snprintf.
>
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
[ application/x-gzip is not supported, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I have since sent out a message stating this has already been applied. Sorry you missed that. As far as the stable tree, I don't think we are releasing any more 7.1.X versions. > On Fri, Sep 07, 2001 at 02:34:03PM -0400, Bruce Momjian wrote: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://candle.pha.pa.us/cgi-bin/pgpatches > > > > I will try to apply it within the next 48 hours. > > Please don't do that Bruce. Patches 0-3 are already applied. Patch in this > form is buggy. Christof already send me a corrected version but I haven't > found the time to check it and the following patches. > > He'd also like to see at least patch 0 in STABLE too. Is this possible? I > cannot see how it could break anything. > > Michael > -- > Michael Meskes > Michael@Fam-Meskes.De > Go SF 49ers! Go Rhein Fire! > Use Debian GNU/Linux! Use PostgreSQL! > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, Sep 07, 2001 at 02:34:03PM -0400, Bruce Momjian wrote: > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://candle.pha.pa.us/cgi-bin/pgpatches > > I will try to apply it within the next 48 hours. Please don't do that Bruce. Patches 0-3 are already applied. Patch in this form is buggy. Christof already send me a corrected version but I haven't found the time to check it and the following patches. He'd also like to see at least patch 0 in STABLE too. Is this possible? I cannot see how it could break anything. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!