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

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 (view raw or flat)
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

pgsql-interfaces by date

Next:From: Bruce MomjianDate: 2003-02-13 01:49:34
Subject: Re: Prepare and prepare ?
Previous:From: Rudy LippanDate: 2003-02-13 00:42:17
Subject: Re: Prepare and prepare ?

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