Skip site navigation (1) Skip section navigation (2)

Re: DBD::PgSQL: More Queestions

From: David Wheeler <david(at)wheeler(dot)net>
To: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Cc: dbi-dev(at)perl(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: DBD::PgSQL: More Queestions
Date: 2002-11-21 02:03:00
Message-ID: 5C9E6A6E-FCF5-11D6-8943-0003931A964A@wheeler.net (view raw or flat)
Thread:
Lists: pgsql-interfaces
First, I want to thank everyone who has responded to my posts. I know 
that they're chock full 'o newbie questions, and I *really* appreciate 
the patient explanations that all you folks are taking the time to send 
to me. I *really* appreciate it. The only side affects are that I now 
have to spend much more time writing and responding to emails, and that 
I'm much more motivated to spend the time getting to know the code so 
that I have the knowledge to create an effective update. I couldn't 
have done it without you all. Thanks!

On Wednesday, November 20, 2002, at 02:49  AM, Tim Bunce wrote:

> Drivers should rarely if ever print anything below trace level 3.
> Quite a few drivers get this wrong and it can be quite annoying to
> the users to have to wade through lots of driver output when all
> they want is the basic DBI level 1 or 2 trace.  Use levels around
> 4 through 7 to add more (obscure) detail.

So, 4 for more informative stuff, and down through 7 to report, say, 
every function executed?

> I believe dTHR is only needed for the old "5.005 threads", not the
> new iThreads, and the DBI will no longer support the old 5.005 threads
> so you can delete them all for your new driver.

Okay. Thanks for the tip.

> Some databases, like Oracle, have what you could call a "server-side
> prepare" so DBD::Oracle's prepare() method sends the statement to
> the server and then asks the server to 'describe' it.

PostgreSQL 7.3 has a "server-side prepare" that I'd like to take 
advantage of, but I don't think it offers any way to then "describe" 
the prepared statement.

> (Without that you'd need a full sql parser available on the client
> side.  Even then you wouldn't know the TYPE of the database fields
> without much more work.)

Yep, I'll steer *far* clear of that! :-)

> That's the wrong question. The DBI spec actually makes no assumptions
> about the syntax of the statements. But it does say that question marks
> should be used for placeholders.
>
> Thing is, users tend to get upset (quite reasonably) when a driver
> interprets question marks that are inside comments as real 
> placeholders.

I guess I've never seen users use comments in SQL they're passing to 
the DBI. I personally tend to use Perl comments.

> Personally I'd agree with them that it's a driver, er, limitation
> (so I'm not over-happy with DBD::ODBC ducking the issue, but I
> understand that DBD::ODBC faces a much tougher issue here than most 
> drivers).

Okay. Perhaps I'll leave it in, then. But if I decide not to use 
PostgreSQL 7.3's server-side prepare functionality, and I still need to 
parse statements for every execute, I think that I might then eliminate 
them from the query in dbd_preparse() so that dbd_st_execute() doesn't 
have to worry about them.

> Why should dbd_st_execute have to "deal" with them? The whole string
> should just be sent off to the server.

I believe that others have answered better than I. The short answer: no 
support for sever-side prepare up to now, so dbd_st_execute has to 
parse the statement again every time.

> If it's possible for you to _realiably_ determine the number of
> field at prepare() time, then you should do it. If not, then do it
> on just the *first* execute().

Yeah, I'm not sure that I want to do that kind of parsing in 
dbd_preparse.

> phs stands for placeholder structure. The structure (typedef) is 
> declared
> in one of the driver *.h files. There's one per placeholder and they're
> store in the hash pointed to by imp_sth->all_params_hv. All that's done
> by dbd_preparse() as it scans the statement string.

Thanks. With the help of some of the other replies (notably Jeff's), 
and careful examination of DBD::Pg's and DBD::ODBC's code, I think I'm 
starting to follow what's happening there.

Thanks again for the help, Tim!

Regards,

David

-- 
David Wheeler                                     AIM: dwTheory
david(at)wheeler(dot)net                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Theory(at)jabber(dot)org


In response to

Responses

pgsql-interfaces by date

Next:From: David WheelerDate: 2002-11-21 03:02:12
Subject: Re: DBD::PgSQL: More Queestions
Previous:From: Jeff UrlwinDate: 2002-11-20 16:36:58
Subject: Re: :PgSQL: More Queestions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group