On Fri, 30 May 2003, Tom Lane wrote:

> Rudy Lippan <[EMAIL PROTECTED]> writes:
> > On Thu, 29 May 2003, David Wheeler wrote:
> >>>> disabled until PREPARE works a little better
> >> 
> >> Pity. Do you know if it will work as well as you need in 7.4? Have you 
> >> tested it with the latest from CVS? I think that it is close-ish to 
> >> done, so now would be the time to get in any requests for fixes.
> 
> > I need to test this, I'll play with it next week.
> 
> It *is* done.  The window for offering any feedback is shrinking fast,
> so I'd definitely encourage you to look at it ASAP.
> 

developer.postgresql.org seems to be down?  Grrr.

OK. At least with 7.3, PREPARE required you to enumerate the field types
passed in, but DBD::Pg does not have a clue as to what the data types will
be until bind, and at bind time the driver mostly just guesses -- varchar
being the default.  Now this worked most of the time; however, for some
field types, this really screwed with Postgres (from the apps POV) as an
example:

... (varchar, varchar) ...  WHERE date_column BETWEEN $1 and $2.

I looked into the required field types a few months ago, and from what I
remember it did not look like the the (varchar,....) was required for
anything useful, but rather added as a hack to get past the parse stage?
Besides the types end up getting checked again at EXECUTE time (and IIRC, 
casts could confuse things ...(varchar) ... $1::fildtypethatcauseserror).

So my complaint with the prepare in 7.3 is that you have specify field 
types which the DBD driver cannot even guess at until bind time at the 
earliest, and might not even know after execute().  So What I would need 
to make prepare work cleanly with DBI is one of three things (that I can 
think of off the top of my head) 1. A way to ask PostgreSQL what datatypes
types need to be specified  or 2. Have PostgreSQL automatically fill in 
the datatypes for me. or 3. A datatype that works with all existing 
datatypes and gets cast correctly at execute time.


If 7.4 has something that I can work with I will re-enable the automatic 
prepare of statements (but right now developer.postgresql.org is not 
giving me any love, so I cannot check).


TTYL,

Rudy

Reply via email to