Re: :PgSQL: More Queestions

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