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
[EMAIL PROTECTED] ICQ: 15726394
Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
