Re: Prepare and prepare ?

From: David Wheeler <david(at)wheeler(dot)net>
To: Rudy Lippan <rlippan(at)remotelinux(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org, <dbi-dev(at)perl(dot)org>, <dbi-users(at)perl(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Prepare and prepare ?
Date: 2003-02-13 01:30:58
Message-ID: CDD3F8AA-3EF2-11D7-9847-0003931A964A@wheeler.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

On Wednesday, February 12, 2003, at 07:42 PM, Rudy Lippan wrote:

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

Oh, well we can create a branch for the old version. Bruce, do you have
a CVS tag convention that you like to use?

> 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?

Either way. I can give you ownership if you like, but even if I don't
you can still upload releases. Let me know your preference.

> 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?

Tell me your GBorg login name and I'll give it to you.

> 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.

Makes sense.

> 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.

Yes. DBI::DBD says that dbdimp.h in part

defines macros that rename the generic names
like dbd_db_login to database specific names like
ora_db_login. This avoids name clashes and enables use of
different drivers when you work with a statically linked
perl.

> 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).

Tom has made some mumblings about making this easier, but I don't know
if anything has been done. But I was under the assumption that if you
used "text" for the data types that they would be cast without too much
trouble.

> 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.

This is beyond my limited knowledge, I'm afraid.

> 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.

Absolutely.

Regards,

David

--
David Wheeler AIM: dwTheory
david(at)kineticode(dot)com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org
Kineticode. Setting knowledge in motion.[sm]

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Bruce Momjian 2003-02-13 01:49:34 Re: Prepare and prepare ?
Previous Message Rudy Lippan 2003-02-13 00:42:17 Re: Prepare and prepare ?