Re: ECPG enhancements / fixes - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: ECPG enhancements / fixes
Date
Msg-id 200109072156.f87LubV00575@candle.pha.pa.us
Whole thread Raw
In response to ECPG enhancements / fixes  (Christof Petig <christof@petig-baender.de>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Patch for jdbc2 ResultSet.java
Next
From: Bruce Momjian
Date:
Subject: Re: ADD CONSTRAINT UNIQUE patch