Re: :PgSQL: More Queestions - Mailing list pgsql-interfaces
| From | David Wheeler |
|---|---|
| Subject | Re: :PgSQL: More Queestions |
| Date | |
| Msg-id | A94E346C-FCFE-11D6-8943-0003931A964A@wheeler.net Whole thread Raw |
| Responses |
Re: :PgSQL: More Queestions
Re: :PgSQL: More Queestions Re: :PgSQL: More Queestions |
| List | pgsql-interfaces |
On Wednesday, November 20, 2002, at 08:36 AM, Jeff Urlwin wrote:
> See the other posts. They did a better job of describing it.
Right, thanks.
> I'm not sure what it's really trying to do, either, really...
Heh. Thank God we have Tim Bunce to explain it to use mere mortals. ;-)
>> Maybe it's just too complex, because, looking at DBD::ODBC's
>> dbd_preparse(), the handling of literals in the query seems a good
>> deal
>> more straight-forward (though it doesn't appear to handle '\'' or "\""
>> -- am I reading that right?
>
> Nope, it handles " or '.
>
> if (*src == '"' || *src == '\'') {
> etc...
> }
It doesn't appear to handle "...""...", though, right? Or am I missing
it?
>> Ah, that makes sense. Not sure if it's an issue for PostgreSQL, but I
>> doesn't appear to be much of an overhead to set it on a per-execute
>> basis...
>
> Actually, if you can get away with doing it only once, the first
> execute, go
> with it. DBD::ODBC tries to do that, but rechecks under two
> conditions:
> 1) we "know" there are multiple result sets in this query via already
> experiencing it
> 2) the user sets a DBD::ODBC private attributed to recheck the result
> set
> types (this is to support nasty things like stored procedures
> returning only
> one result set per call, but a different result set based upon the
> input
> (yes, I've seen this!).
Bleh!
> My advice: if you don't have to support multiple result sets, do it
once per
> execute. If you setup that "flag" to avoid re-doing work and find
> that you
> need to support multiple-result sets, you can always clear the flag...
I'll have to check with the PostgreSQL folks on this.
PostgreSQL folks, can the same statement return a different number of
fields on different executes? I'm guessing yes for something like this,
though:
CREATE TABLE foo ( bar int, bat, text);
SELECT * FROM foo; -- Returns two fields.
ALTER TABLE foo ADD COLUMN fat int;
SELECT * FROM foo; -- Returns three fields.
> I would make the statement that DBD::Oracle may provide a better
> reference
> on the pre-parse stuff. DBD::ODBC's is probably a bit watered down
> from
> DBD::Oracle -- especially because I'm avoiding comments.
Yep, thanks, I'll check it out.
Regards,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e Jabber:
Theory@jabber.org
pgsql-interfaces by date: