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: