Re: Prepare and prepare ?

On Wed, 12 Feb 2003, David Wheeler wrote:

>
> > I'd like to start putting together some developer releases (set up a
> > cvs
> > branch for this?), and see about getting together a stable release
> > version
> > that addresses the all of the outstanding problems with DBD::Pg.
> >
> > So, if people are interested, where do I go from here to get things set
> > up for doing dev releases &c.?
>
> No need for a separate branch, I think. Just change the version number
> to have an undersore, e.g., 1.30_01. That will automatically make it a
> beta release number when it's put on CPAN.
>

I was thinking more for bug fixes agaist the old version before the
devel release are tested enough to go to production.

As for CPAN, should I go ahead set up a PAUSE account (I need to anyway)
for making the dev release, or do you want to handle making the releases?
(I warn you, though, that I am planing on releasing quite often until I
get a release that is stable enough for a production environment ;) ) If
the former what would need to be done to get CPAN to pick up my uploads as
part of DBD::Pg?

I signed up for the DBD::Pg project on gborg.org few days ago, so what do
I need to do to get CVS commit access?

> Cool.
>
> > 2. Allows the use of :n and :foo bind params. So: (SELECT * FROM foo
> > where
> > 1 = :this and 2 = :that) will now work.
>
> Oh, was that broken?
>

I think that the docs say that it does not work, but the code (from
DBD::oracle) was still there in preparse and bind, so it would work up
until execute() where it would break because execute was not looking for
:foo style placeholders.

This version saves the values for placeholer 1..n in an array and just
uses the key :foo as a lookup for the index into that array.

>
> > 5. pg_error() only removes \n's don't truncate message on first \n
>
> Oh, good. I think it should be changed to do_error, too, with renaming
> in dbdimp.h, no?
>

To get away from possible namespace collisions with libpq? the libpq
functions start with PQ..., BTA pg_eror should probably be declared
static as should several other functions.

> > 8. :veryverylongplaceholdername == Long walk. Sort pier -- fixed.
> >
> > 9. quote() is now in C and uses same code as bind_param.
>
> Nice. Faster, t hen.

Probably. But the big win is that it uses the same quoting code that
bind_param does; therefore, they both use the libpq quoting function.

> > 12. fixed many heap buffer overruns.
>
> Do you include tests for all of these things, too? That'd be great.

Yup. But they are not in the patch.

>
> > Known problems with patch:
> >
> > 1. Broke new pg_bool_tf attribute.
>
> Ah. Can be fixed, I assume?
>

Yeah. This just comes about because the way I implemented quoting. There
is a struct of pq_types that contains pointers to quote and dequote
functions. Right now the quote and dequote functions don't know anything
about perl/dbi... "Take string send to libpq return string returned from
libpq."

> > 3. quote("stuff", {typeinfo }) is broken (only when hashref is passed
> > in)
>
> Probably is never used, anyway. Or shouldn't be. Is it fixable?
>

These are the calls that are broken:
quote(foo, {type=>SQL_INTEGER})
quote(foo, {pg_type=>DBD::Pg::PG_INTEGER})

Which I do see being used. So this fix is at the top of my list.

> > 6. PREPARE is not bullet-proof casts in RSH of equality and functions
> > LHS of equality can break serverside prepare, so decide exactly how
> > to
> > do this and how to get prepares of INSERT statements to work? Move
> > prepqre to execute and build list column list in bind_param? Add
> > attributes to prepare to identify the columns and serverside
> > prepare if
> > they exist?
>
> Not sure I understand the problems here. Is it weaknesses in
> PostgreSQL's PREPARE?

Yes. PostgreSQL's PREPARE wants a list of column types when you call
prepare, so as proof of concept I did a (varchar, varchar, varchar...) for
the column types, but that ends up breaking some things (like UPDATE
INSERT, and when it checks an operation for castability).

Which does not make sense to me... postgres knows the fields types why
does it not set them correctly instead of making the application
programmer enumerate them... (or maybe give a type that causes pg to
not do checking. -- pg does the checks twice once on prepare and then it
does them again on execute, so again why not just sub in the correct types
if nothing was enumerated beforhand on prepare and let the checks on
execute handle the type checks?. Or am I missing something? Grr.

>
> > 2. Export the full list of supported OID types.
>
> For constants? I think I added a partial list in 1.20.
>

I know, those might be easier for the user, but for all interal stuff, I
am using the ones extraced from pg header files:

grep '^#define' /data/dnloads/postgresql-7.3/src/include/catalog/pg_type.h
|grep OID >pg_typeOID.h

And I think that they should be available to the perl programmer as well.

> > 8. rewrite hacked version detection code (and get format for string so
> > it is done correctly with patch level &c.).
>
> You'll want to borrow code from PostgreSQL's ODBC implementation for
> this, I think. Tim sent some links a while ago.
>

I'll look at doing that. Might save me some work :)

-r