Re: Prepare and prepare ? - Mailing list 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@kineticode.com                              ICQ: 15726394                                               Yahoo!:
dew7e                                              Jabber: Theory@jabber.org
 
Kineticode. Setting knowledge in motion.[sm]