pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedPrepare and prepare ?
27+ messages / 4 participants
[nested] [flat]
* Prepare and prepare ?
@ 2003-01-23 14:34 Kaare Rasmussen <kar@kakidata.dk>
0 siblings, 1 reply; 27+ messages in thread
From: Kaare Rasmussen @ 2003-01-23 14:34 UTC (permalink / raw)
To: pgsql-interfaces
I saw some previous mailings re DBI's prepare ind DBD::Pg.
I'm not sure what the state is for supporting the prepare in PostgreSQL
7.3.1?
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk
2000 Frederiksberg Lørdag 12.00-16.00 Email:kar@kakidata.dk
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-01-24 01:31 David Wheeler <david@wheeler.net>
parent: Kaare Rasmussen <kar@kakidata.dk>
0 siblings, 1 reply; 27+ messages in thread
From: David Wheeler @ 2003-01-24 01:31 UTC (permalink / raw)
To: Kaare Rasmussen <kar@kakidata.dk>; +Cc: pgsql-interfaces
On Thursday, January 23, 2003, at 06:34 AM, Kaare Rasmussen wrote:
> I saw some previous mailings re DBI's prepare ind DBD::Pg.
> I'm not sure what the state is for supporting the prepare in
> PostgreSQL 7.3.1?
I'm planning to implement a new PostgreSQL DBI driver with prepare
support, but paying work has come between me and that project. It's
going to be a while before I can get back to it, I think.
Meanwhile, you can use DBD::Pg and its prepare method, and when I
finally get around to writing the new driver, you should be able to
upgrade without much difficulty.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-05 03:46 Rudy Lippan <rlippan@remotelinux.com>
parent: David Wheeler <david@wheeler.net>
0 siblings, 0 replies; 27+ messages in thread
From: Rudy Lippan @ 2003-02-05 03:46 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Kaare Rasmussen <kar@kakidata.dk>; pgsql-interfaces; dbi-dev@perl.org
I just happend upon this message while catching up on pgsql-interfaces...
On Thu, 23 Jan 2003, David Wheeler wrote:
> Date: Thu, 23 Jan 2003 17:31:11 -0800
> From: David Wheeler <david@wheeler.net>
> To: Kaare Rasmussen <kar@kakidata.dk>
> Cc: pgsql-interfaces@postgresql.org
> Subject: Re: [INTERFACES] Prepare and prepare ?
>
> On Thursday, January 23, 2003, at 06:34 AM, Kaare Rasmussen wrote:
>
> > I saw some previous mailings re DBI's prepare ind DBD::Pg.
> > I'm not sure what the state is for supporting the prepare in
> > PostgreSQL 7.3.1?
>
> I'm planning to implement a new PostgreSQL DBI driver with prepare
> support, but paying work has come between me and that project. It's
> going to be a while before I can get back to it, I think.
>
> Meanwhile, you can use DBD::Pg and its prepare method, and when I
> finally get around to writing the new driver, you should be able to
> upgrade without much difficulty.
Back over Thanksgiving, I kludged together a proof of concept
'DBD::ChurlPg' that does serverside prepare() for DML statements [among
some other things that I wanted.] I did this for myself, so I was not
going to show it to anyone, but what the heck.
If you are intersted in taking a look, the code is here:
http://www.remotelinux.com/rlippan/ There is some uglyness in there and
rows() is broken (it is using default from driver.xst), but otherwise it
has been working for me for the past few months.
I'd love to get some feedback on the changes that I made. And if wanted
(read other's will think that the changes are useful), I will clean up the
code and port the changes over to the latest version of DBD::Pg.
-r
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-12 03:51 Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-02-12 03:51 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>; dbi-users@perl.org
On Thu, 6 Feb 2003, David Wheeler wrote:
> Unfortunately I have no time to work on DBD::Pg stuff right now. :-(
> I'll have to rely on others to evaluate your approach. Post to the
> dbi-dev list, too -- those folks have a better idea on how to implement
> DBI drivers, I think.
>
> I hope I can find time to get back to this stuff one day, but I'm
> (happily) way too busy right now.
>
> Regards,
>
> David
>
Since David is too busy to work on DBD::Pg right now, I have ported the
changes that I made against 1.13 to CVS HEAD from gborg.postgresql.org.
The patch can be found here:
http://www.remotelinux.com/rlippan/dbd_pg.patch (I did not include it in
this email because I did not want to spam everyone with a 100K diff).
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.?
What the patch does:
1. $dbh->prepare() rewrites the SQL statement into an internal for
striping out comments and whitespace, and if PostgreSQL > 7.3 takes the
stripped statement
and passes that to postgress' PREPARE statement, then rewrites the
statement as 'EXECUTE "DBD::PG::cached_query n" ($1, $2, ... $n, $n+1)'
for DBD::Pg's execute.
2. Allows the use of :n and :foo bind params. So: (SELECT * FROM foo where
1 = :this and 2 = :that) will now work.
3. Complains on execute when unbound bind params are submitted (instead of
defaulting to NULL)
4. Switched over to use driver.xst.
5. pg_error() only removes \n's don't truncate message on first \n
6. fixed statement scan problem where the preparse of
"SELECT foo[3:33] from bar" was scanning :33 as a placeholder
7. moved the quoting of bind values out of execute() and into
bind -- as there is no need to requote the value every time execute
is called.
8. :veryverylongplaceholdername == Long walk. Sort pier -- fixed.
9. quote() is now in C and uses same code as bind_param.
10. quoting and dequoting now use libpq quoting functions where available
(I still need
to take the libpq functions swiped out of quote.c and move it into
libpqswip.c
with license info &c., and switch ifndefs to ifdefs)
11. bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is
PGBOOLOID.
12. fixed many heap buffer overruns.
Known problems with patch:
1. Broke new pg_bool_tf attribute.
2. Broke rows() method (Just needs a define in makefile)
3. quote("stuff", {typeinfo }) is broken (only when hashref is passed in)
4. broke chopblanks.
5. has some // style comments around debug statements that need to be
converted into logging statements
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?
7. Code is not as clean as it should be -- some kludgeness in there.
8. Documentation has not been updated.
9. Needs more tests.
On my immediate todo list:
1. Change quote and dequote functions to take Sv instead of string so that
things like arrays can be seralized by the quote function. This will
take care of broken chopblanks and pg_bool_tf (pass the quote/dequote
options struct to function quote/dequote functions).
2. Export the full list of supported OID types.
3. finish all type mappings in types.c
4. supoort for begin_work() method.
5. clean logging and trace levels.
6. dblogin to handle user names, table table names and other
names that containg ';'s
7. add attributes to control preparing of statements.
8. rewrite hacked version detection code (and get format for string so
it is done correctly with patch level &c.).
9. various code cleanups and polishing.
10. Copy over external test cases from DBD::Churlpg and write more tests.
11. Update documentation.
There are probably many other things that I cannot remember off the top of
my head since I have not done much (other than copy code over to CVS head)
with this code since late Nov/ early Dec.
-r
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-12 15:51 David Wheeler <david@wheeler.net>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 1 reply; 27+ messages in thread
From: David Wheeler @ 2003-02-12 15:51 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>; dbi-users@perl.org
On Tuesday, February 11, 2003, at 10:51 PM, Rudy Lippan wrote:
> Since David is too busy to work on DBD::Pg right now, I have ported the
> changes that I made against 1.13 to CVS HEAD from gborg.postgresql.org.
> The patch can be found here:
> http://www.remotelinux.com/rlippan/dbd_pg.patch (I did not include it
> in
> this email because I did not want to spam everyone with a 100K diff).
Wow. Reading your description below, I'm really impressed. That's a lot
of work! Good thing I stepped aside! ;-)
> 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.
> What the patch does:
>
> 1. $dbh->prepare() rewrites the SQL statement into an internal for
> striping out comments and whitespace, and if PostgreSQL > 7.3 takes
> the
> stripped statement
> and passes that to postgress' PREPARE statement, then rewrites the
> statement as 'EXECUTE "DBD::PG::cached_query n" ($1, $2, ... $n,
> $n+1)'
> for DBD::Pg's execute.
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?
> 3. Complains on execute when unbound bind params are submitted
> (instead of
> defaulting to NULL)
Didn't know about that one.
> 4. Switched over to use driver.xst.
Yay!
> 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?
> 6. fixed statement scan problem where the preparse of
> "SELECT foo[3:33] from bar" was scanning :33 as a placeholder
>
> 7. moved the quoting of bind values out of execute() and into
> bind -- as there is no need to requote the value every time execute
> is called.
Cool.
> 8. :veryverylongplaceholdername == Long walk. Sort pier -- fixed.
>
> 9. quote() is now in C and uses same code as bind_param.
Nice. Faster, t hen.
> 10. quoting and dequoting now use libpq quoting functions where
> available
> (I still need
> to take the libpq functions swiped out of quote.c and move it into
> libpqswip.c
> with license info &c., and switch ifndefs to ifdefs)
Excellent.
> 11. bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is
> PGBOOLOID.
Smart.
> 12. fixed many heap buffer overruns.
Do you include tests for all of these things, too? That'd be great.
> Known problems with patch:
>
> 1. Broke new pg_bool_tf attribute.
Ah. Can be fixed, I assume?
> 2. Broke rows() method (Just needs a define in makefile)
>
> 3. quote("stuff", {typeinfo }) is broken (only when hashref is passed
> in)
Probably is never used, anyway. Or shouldn't be. Is it fixable?
> 4. broke chopblanks.
>
> 5. has some // style comments around debug statements that need to be
> converted into logging statements
>
> 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?
> 7. Code is not as clean as it should be -- some kludgeness in there.
Oh, well *that's* not new! ;-)
> 8. Documentation has not been updated.
>
> 9. Needs more tests.
>
>
>
> On my immediate todo list:
>
> 1. Change quote and dequote functions to take Sv instead of string so
> that
> things like arrays can be seralized by the quote function. This
> will
> take care of broken chopblanks and pg_bool_tf (pass the
> quote/dequote
> options struct to function quote/dequote functions).
Cool.
> 2. Export the full list of supported OID types.
For constants? I think I added a partial list in 1.20.
> 3. finish all type mappings in types.c
>
> 4. supoort for begin_work() method.
>
> 5. clean logging and trace levels.
>
> 6. dblogin to handle user names, table table names and other
> names that containg ';'s
>
> 7. add attributes to control preparing of statements.
>
> 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.
> 9. various code cleanups and polishing.
>
> 10. Copy over external test cases from DBD::Churlpg and write more
> tests.
>
> 11. Update documentation.
>
> There are probably many other things that I cannot remember off the
> top of
> my head since I have not done much (other than copy code over to CVS
> head)
> with this code since late Nov/ early Dec.
Still, it's a lot of work. I had no idea you'd done this, Rudy. I
suspect that once you get this committed, others will contribute, as it
represents the first real advances in DBD::Pg in years. I'll help out
where I can, too.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 00:42 Rudy Lippan <rlippan@remotelinux.com>
parent: David Wheeler <david@wheeler.net>
0 siblings, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-02-13 00:42 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>; dbi-users@perl.org
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
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 01:30 David Wheeler <david@wheeler.net>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 2 replies; 27+ messages in thread
From: David Wheeler @ 2003-02-13 01:30 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>; dbi-users@perl.org; Bruce Momjian <pgman@candle.pha.pa.us>
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]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 01:49 Bruce Momjian <pgman@candle.pha.pa.us>
parent: David Wheeler <david@wheeler.net>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2003-02-13 01:49 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Rudy Lippan <rlippan@remotelinux.com>; pgsql-interfaces; dbi-dev@perl.org; dbi-users@perl.org
David Wheeler wrote:
> 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?
Let's get the small UTF patch into a DBD:pg release, then we can just
put it all into the main CVS and do a beta/final release with his
changes. I don't see why we need to create a branch.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 02:40 David Wheeler <david@wheeler.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: David Wheeler @ 2003-02-13 02:40 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Rudy Lippan <rlippan@remotelinux.com>; pgsql-interfaces; dbi-dev@perl.org; dbi-users@perl.org
On Wednesday, February 12, 2003, at 08:49 PM, Bruce Momjian wrote:
> Let's get the small UTF patch into a DBD:pg release, then we can just
> put it all into the main CVS and do a beta/final release with his
> changes. I don't see why we need to create a branch.
Works for me...unless Rudy's planning to break the backwards
compatibility of the UTF-8 patch. ;-)
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 03:32 Rudy Lippan <rlippan@remotelinux.com>
parent: David Wheeler <david@wheeler.net>
1 sibling, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-02-13 03:32 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>
On Wed, 12 Feb 2003, David Wheeler wrote:
> On Wednesday, February 12, 2003, at 07:42 PM, Rudy Lippan wrote:
>
> 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 will go fill out the PAUSE account form tomorrow morning, & when I do
I will ask if ownership is required.
> > 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.
>
rlippan
> > 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.
>
Maybe I will go over to PostgreSQL hackers and cause some trouble ;) It is
a *major* pain. I looked at PostgreSQL & it looks do-able, just
non-trivial.
-r
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 03:56 Rudy Lippan <rlippan@remotelinux.com>
parent: David Wheeler <david@wheeler.net>
0 siblings, 0 replies; 27+ messages in thread
From: Rudy Lippan @ 2003-02-13 03:56 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Rudy Lippan <rlippan@remotelinux.com>; pgsql-interfaces; dbi-dev@perl.org; dbi-users@perl.org
On Wed, 12 Feb 2003, David Wheeler wrote:
>
> On Wednesday, February 12, 2003, at 08:49 PM, Bruce Momjian wrote:
>
> > Let's get the small UTF patch into a DBD:pg release, then we can just
> > put it all into the main CVS and do a beta/final release with his
> > changes. I don't see why we need to create a branch.
Sounds good to me.
>
> Works for me...unless Rudy's planning to break the backwards
> compatibility of the UTF-8 patch. ;-)
>
I would rather it be done the right way the first time; that being said,
we can add the whatever_utf_8 (don't remember name from patch) attribute
and then: 1) Flag it in the docs as expermental and don't use. 2)
or when DBD::Pg decides that PostgreSQL wants to send UTF data, use the
whatever_utf_8 attribute to decide whether to flag the returned data as
such (ie. set the default to false for now, & if whatever_utf_8 is true
trun on UTF for all data coming out of the db. Then in the next version
set the default to true, and set UTF8 iff whatever_utf_8 is true and
DBD::Pg the client character set is UTF8). 3) do both. 4) do something
better.
With 2, the patch goes in as is and backwards compatibility does not
get broken in the next version. Just a thought.
Ideas, Suggestions?
-r
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-13 06:16 David Wheeler <david@wheeler.net>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 0 replies; 27+ messages in thread
From: David Wheeler @ 2003-02-13 06:16 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: pgsql-interfaces@postgresql.org, <dbi-dev@perl.org>
On Wednesday, February 12, 2003, at 10:32 PM, Rudy Lippan wrote:
>> Tell me your GBorg login name and I'll give it to you.
>
> rlippan
You're now officially a developer. :-)
> Maybe I will go over to PostgreSQL hackers and cause some trouble ;)
> It is
> a *major* pain. I looked at PostgreSQL & it looks do-able, just
> non-trivial.
Good idea, though they've been known to join discussions on the
interfaces list, too.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-15 15:46 Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 2 replies; 27+ messages in thread
From: Rudy Lippan @ 2003-02-15 15:46 UTC (permalink / raw)
To: Dominic Mitchell <dom@semantico.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-interfaces; David Wheeler <david@wheeler.net>; dbi-dev@perl.org
On Thu, 13 Feb 2003, Dominic Mitchell wrote:
> Well at the moment, backwards compatibility is limited to one system at
> our place that needed the funtionality right now. We'll change it to
> use whatever DBD::Pg comes with, however.
Right, but once it goes into a public release (eg. DBD::Pg 1.22) then you
are stuck supporting it/making a migration path.
> > With 2, the patch goes in as is and backwards compatibility does not
> > get broken in the next version. Just a thought.
>
> #2 sounds good to me.
>
The we go this route.
> The flag was called, "pg_do_utf8", but "pg_enable_utf8" might be a
> better name.
>
Agreed. pg_enable_utf8 the flag is, then. I'll go apply the patch --
changing pg_do_utf8 to pg_enable_utf8.
David/Bruce,
1. Looking over CVS I don't see a release tag for 1.21. It would proably
be better for whoever did the export of 1.21 to tag up, but if you want I
will set up a release tag for 1.21?
2. What is the procedure for adding patches, closing bugs, working with
tasks, and working with feature requests on GBorg... Is there a place
where I can get an overview of how things are done?
-r
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-02-15 16:14 David Wheeler <david@wheeler.net>
parent: Rudy Lippan <rlippan@remotelinux.com>
1 sibling, 0 replies; 27+ messages in thread
From: David Wheeler @ 2003-02-15 16:14 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: Dominic Mitchell <dom@semantico.com>; Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-interfaces; dbi-dev@perl.org
On Saturday, February 15, 2003, at 07:46 AM, Rudy Lippan wrote:
> 1. Looking over CVS I don't see a release tag for 1.21. It would
> proably
> be better for whoever did the export of 1.21 to tag up, but if you
> want I
> will set up a release tag for 1.21?
Yes, please. Use the same tagging style as was used for 1.20. And yes,
I'd like us to be consistent and do that with all future releases.
> 2. What is the procedure for adding patches, closing bugs, working with
> tasks, and working with feature requests on GBorg... Is there a place
> where I can get an overview of how things are done?
Right here. As long as there's some level of consensus on the mail
list, I think it's cool to apply patches.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-14 20:25 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rudy Lippan <rlippan@remotelinux.com>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2003-03-14 20:25 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: Dominic Mitchell <dom@semantico.com>; pgsql-interfaces@postgresql.org, David Wheeler <david@wheeler.net>; dbi-dev@perl.org
To answer your question from a month ago :-), we should have CVS tagged
the 1.21 release, but we forgot. I didn't think we were big enough to
tag things. :-)
We don't have any master plan on development --- we just discuss items
and apply patches.
---------------------------------------------------------------------------
Rudy Lippan wrote:
> On Thu, 13 Feb 2003, Dominic Mitchell wrote:
>
> > Well at the moment, backwards compatibility is limited to one system at
> > our place that needed the funtionality right now. We'll change it to
> > use whatever DBD::Pg comes with, however.
>
> Right, but once it goes into a public release (eg. DBD::Pg 1.22) then you
> are stuck supporting it/making a migration path.
>
> > > With 2, the patch goes in as is and backwards compatibility does not
> > > get broken in the next version. Just a thought.
> >
> > #2 sounds good to me.
> >
>
> The we go this route.
>
> > The flag was called, "pg_do_utf8", but "pg_enable_utf8" might be a
> > better name.
> >
>
> Agreed. pg_enable_utf8 the flag is, then. I'll go apply the patch --
> changing pg_do_utf8 to pg_enable_utf8.
>
>
>
> David/Bruce,
>
> 1. Looking over CVS I don't see a release tag for 1.21. It would proably
> be better for whoever did the export of 1.21 to tag up, but if you want I
> will set up a release tag for 1.21?
>
> 2. What is the procedure for adding patches, closing bugs, working with
> tasks, and working with feature requests on GBorg... Is there a place
> where I can get an overview of how things are done?
>
>
> -r
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-26 04:29 Rudy Lippan <rlippan@remotelinux.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-03-26 04:29 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; David Wheeler <david@wheeler.net>; dbi-dev@perl.org
On Fri, 14 Mar 2003, Bruce Momjian wrote:
>
> To answer your question from a month ago :-), we should have CVS tagged
> the 1.21 release, but we forgot. I didn't think we were big enough to
> tag things. :-)
Bruce,
To respond to your message of a week or so ago :-)
I tagged it up a while ago -- Just so that I can keep myself sane.
I also created a Dev-1_3 branch because my patch conflicted with the array
patch that you merged [more on that later]. Anyway I applied my patch on
the Dev-1_3 branch -- I did this because it conflicted with the uft_8 patch
and I think there was some interest in putting out a utf enable release
before 1_3.
One thing to note about the Dev-1_3 tree I disabled the server-side
prepare of statements because what I was doing to hack them in was causing
more problems that it was was worth. If we can get a clean way for the
server to prepare statements, I will re-enable server-side prepares, and I
don't think that bind_param(":foo", 1, {type=>'varchar'}) is the way to
go. So, Basically what I am want is for the server to either 1. ignore
the type checking and only do that at execute time, or 2. give me a list of
types. This should not be to
Now, about the array patch in cvs: I looked it over and I don't
particularly like it for a couple of reasons: 1. the av_shift() and
av_clear() modify the array that was passed in, so if you pass in an
array, all of the data in your array will vanish. 2. escaped quotes can
confuse things 3. isn't sv_catpv a bit expensive to be used there, why not
just malloc what is needed before escaping the string? 4. It conflicts
with the direction I was moving WRT quoting :-) take a look at the way
that Dev-1_3 handles quoting. To do the array quoting I am thinking about
making the quote_* functions take an SV and the dequote_* functions return
an SV. :) 5. The patch does not handle dequoting of arrays.
I have been sitting on getting a developer release out for a little while
now, and I would like to get that out, so that I can get some feed back
and move forward with the other things that I want to get working (like
array quoting/dequoting, full UTF8 support, begin_work(),
quote_identifier, &c.)
Actually, what I have been sitting on is getting a PAUSE ID, which I just
requested :-)
Later,
Rudy.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-26 23:03 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2003-03-26 23:03 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: Dominic Mitchell <dom@semantico.com>; pgsql-interfaces@postgresql.org, David Wheeler <david@wheeler.net>; dbi-dev@perl.org
These all sounds good. Can I get some of them as patches I can apply
now --- having one megapatch usually gets too complex after a while.
---------------------------------------------------------------------------
Rudy Lippan wrote:
> On Fri, 14 Mar 2003, Bruce Momjian wrote:
>
> >
> > To answer your question from a month ago :-), we should have CVS tagged
> > the 1.21 release, but we forgot. I didn't think we were big enough to
> > tag things. :-)
>
> Bruce,
>
> To respond to your message of a week or so ago :-)
>
>
> I tagged it up a while ago -- Just so that I can keep myself sane.
> I also created a Dev-1_3 branch because my patch conflicted with the array
> patch that you merged [more on that later]. Anyway I applied my patch on
> the Dev-1_3 branch -- I did this because it conflicted with the uft_8 patch
> and I think there was some interest in putting out a utf enable release
> before 1_3.
>
> One thing to note about the Dev-1_3 tree I disabled the server-side
> prepare of statements because what I was doing to hack them in was causing
> more problems that it was was worth. If we can get a clean way for the
> server to prepare statements, I will re-enable server-side prepares, and I
> don't think that bind_param(":foo", 1, {type=>'varchar'}) is the way to
> go. So, Basically what I am want is for the server to either 1. ignore
> the type checking and only do that at execute time, or 2. give me a list of
> types. This should not be to
>
>
> Now, about the array patch in cvs: I looked it over and I don't
> particularly like it for a couple of reasons: 1. the av_shift() and
> av_clear() modify the array that was passed in, so if you pass in an
> array, all of the data in your array will vanish. 2. escaped quotes can
> confuse things 3. isn't sv_catpv a bit expensive to be used there, why not
> just malloc what is needed before escaping the string? 4. It conflicts
> with the direction I was moving WRT quoting :-) take a look at the way
> that Dev-1_3 handles quoting. To do the array quoting I am thinking about
> making the quote_* functions take an SV and the dequote_* functions return
> an SV. :) 5. The patch does not handle dequoting of arrays.
>
>
>
> I have been sitting on getting a developer release out for a little while
> now, and I would like to get that out, so that I can get some feed back
> and move forward with the other things that I want to get working (like
> array quoting/dequoting, full UTF8 support, begin_work(),
> quote_identifier, &c.)
>
> Actually, what I have been sitting on is getting a PAUSE ID, which I just
> requested :-)
>
>
> Later,
>
> Rudy.
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 01:47 Rudy Lippan <rlippan@remotelinux.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-03-27 01:47 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; David Wheeler <david@wheeler.net>; dbi-dev@perl.org
On Wed, 26 Mar 2003, Bruce Momjian wrote:
> These all sounds good. Can I get some of them as patches I can apply
> now --- having one megapatch usually gets too complex after a while.
>
I am confused? I thought the plan was to relase a version of DBD::Pg
basied on the 1_21 release with UTF-8 support and then merge in the
patch. This is the reason why I did not apply the mega patch against
HEAD.
So I guess what I am propsing is get 1.22 out (if we even think it is
needed -- I think that we can just get away with putting the UTF-8 stuff
off until 1.3) and then drop Dev-1_30 over HEAD 1_21, then apply
the subsequent patches over that.
Thoughts?
Rudy
> ---------------------------------------------------------------------------
>
> Rudy Lippan wrote:
> > On Fri, 14 Mar 2003, Bruce Momjian wrote:
> >
> > >
> > > To answer your question from a month ago :-), we should have CVS tagged
> > > the 1.21 release, but we forgot. I didn't think we were big enough to
> > > tag things. :-)
> >
> > Bruce,
> >
> > To respond to your message of a week or so ago :-)
> >
> >
> > I tagged it up a while ago -- Just so that I can keep myself sane.
> > I also created a Dev-1_3 branch because my patch conflicted with the array
> > patch that you merged [more on that later]. Anyway I applied my patch on
> > the Dev-1_3 branch -- I did this because it conflicted with the uft_8 patch
> > and I think there was some interest in putting out a utf enable release
> > before 1_3.
> >
> > One thing to note about the Dev-1_3 tree I disabled the server-side
> > prepare of statements because what I was doing to hack them in was causing
> > more problems that it was was worth. If we can get a clean way for the
> > server to prepare statements, I will re-enable server-side prepares, and I
> > don't think that bind_param(":foo", 1, {type=>'varchar'}) is the way to
> > go. So, Basically what I am want is for the server to either 1. ignore
> > the type checking and only do that at execute time, or 2. give me a list of
> > types. This should not be to
> >
> >
> > Now, about the array patch in cvs: I looked it over and I don't
> > particularly like it for a couple of reasons: 1. the av_shift() and
> > av_clear() modify the array that was passed in, so if you pass in an
> > array, all of the data in your array will vanish. 2. escaped quotes can
> > confuse things 3. isn't sv_catpv a bit expensive to be used there, why not
> > just malloc what is needed before escaping the string? 4. It conflicts
> > with the direction I was moving WRT quoting :-) take a look at the way
> > that Dev-1_3 handles quoting. To do the array quoting I am thinking about
> > making the quote_* functions take an SV and the dequote_* functions return
> > an SV. :) 5. The patch does not handle dequoting of arrays.
> >
> >
> >
> > I have been sitting on getting a developer release out for a little while
> > now, and I would like to get that out, so that I can get some feed back
> > and move forward with the other things that I want to get working (like
> > array quoting/dequoting, full UTF8 support, begin_work(),
> > quote_identifier, &c.)
> >
> > Actually, what I have been sitting on is getting a PAUSE ID, which I just
> > requested :-)
> >
> >
> > Later,
> >
> > Rudy.
> >
> >
>
>
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 01:49 David Wheeler <david@wheeler.net>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 1 reply; 27+ messages in thread
From: David Wheeler @ 2003-03-27 01:49 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
On Wednesday, March 26, 2003, at 07:47 PM, Rudy Lippan wrote:
> So I guess what I am propsing is get 1.22 out (if we even think it is
> needed -- I think that we can just get away with putting the UTF-8
> stuff
> off until 1.3) and then drop Dev-1_30 over HEAD 1_21, then apply
> the subsequent patches over that.
>
> Thoughts?
Sounds fine to me.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 02:26 Rudy Lippan <rlippan@remotelinux.com>
parent: David Wheeler <david@wheeler.net>
0 siblings, 1 reply; 27+ messages in thread
From: Rudy Lippan @ 2003-03-27 02:26 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Rudy Lippan <rlippan@remotelinux.com>; Bruce Momjian <pgman@candle.pha.pa.us>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
On Wed, 26 Mar 2003, David Wheeler wrote:
> On Wednesday, March 26, 2003, at 07:47 PM, Rudy Lippan wrote:
>
> > So I guess what I am propsing is get 1.22 out (if we even think it is
> > needed -- I think that we can just get away with putting the UTF-8
> > stuff
> > off until 1.3) and then drop Dev-1_30 over HEAD 1_21, then apply
> > the subsequent patches over that.
> >
> > Thoughts?
>
> Sounds fine to me.
>
David,
Ok. :)
If you transfer DBD::Pg over, I wiill try to get those releases up
tonight.
Thanks,
Rudy
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 03:05 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rudy Lippan <rlippan@remotelinux.com>
0 siblings, 2 replies; 27+ messages in thread
From: Bruce Momjian @ 2003-03-27 03:05 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
OK, so you are saying that the code as exists now in CVS is ready for
release, and once we release, you want to add a lot of stuff, right?
And there is nothing that needs work _before_ we do a release?
---------------------------------------------------------------------------
Rudy Lippan wrote:
> On Wed, 26 Mar 2003, David Wheeler wrote:
>
> > On Wednesday, March 26, 2003, at 07:47 PM, Rudy Lippan wrote:
> >
> > > So I guess what I am propsing is get 1.22 out (if we even think it is
> > > needed -- I think that we can just get away with putting the UTF-8
> > > stuff
> > > off until 1.3) and then drop Dev-1_30 over HEAD 1_21, then apply
> > > the subsequent patches over that.
> > >
> > > Thoughts?
> >
> > Sounds fine to me.
> >
>
> David,
>
> Ok. :)
>
> If you transfer DBD::Pg over, I wiill try to get those releases up
> tonight.
>
> Thanks,
>
> Rudy
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 04:39 Rudy Lippan <rlippan@remotelinux.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 2 replies; 27+ messages in thread
From: Rudy Lippan @ 2003-03-27 04:39 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
On Wed, 26 Mar 2003, Bruce Momjian wrote:
> OK, so you are saying that the code as exists now in CVS is ready for
> release, and once we release, you want to add a lot of stuff, right?
> And there is nothing that needs work _before_ we do a release?
Bruce,
1.21 + UTF-8 patch should be ready to be released as 1.22. We can skip
putting up a 1.22 and jump right to 1.30 alpha if we don't see a need for
getting out the UTF patch? I am easy on this point. So do we want a 1.22
or do we want to jump right to a 1.30 alpha?
The 'a lot of stuff' is already in CVS on the 1_30 branch. I put it there
because I thought we were going to be releasing a 1.22 for basic UTF
support, but since then CVS head has gathered a few other patches that are
not ready for release :(
What I am planing on doing is copying 1_30 over cvs head, making an alpha
release based on that, and then merging all of the patches that were added
since 1.21. (And all new patches against CVS head will be easier to
apply).
The patch that is on the 1_30 branch is here:
ftp://gborg.postgresql.org/pub/dbdpg/1/dbd_pg.patch and I think it would
be much easier to merge a few minor patches rather than the other way
around :)
Thoughs?
Rudy
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 04:40 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2003-03-27 04:40 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Rudy Lippan <rlippan@remotelinux.com>; David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
OK, release DBD-pg 1.22 uploaded to gborg:
http://gborg.postgresql.org/project/dbdpg/download/download.php
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> OK, so you are saying that the code as exists now in CVS is ready for
> release, and once we release, you want to add a lot of stuff, right?
> And there is nothing that needs work _before_ we do a release?
>
> ---------------------------------------------------------------------------
>
> Rudy Lippan wrote:
> > On Wed, 26 Mar 2003, David Wheeler wrote:
> >
> > > On Wednesday, March 26, 2003, at 07:47 PM, Rudy Lippan wrote:
> > >
> > > > So I guess what I am propsing is get 1.22 out (if we even think it is
> > > > needed -- I think that we can just get away with putting the UTF-8
> > > > stuff
> > > > off until 1.3) and then drop Dev-1_30 over HEAD 1_21, then apply
> > > > the subsequent patches over that.
> > > >
> > > > Thoughts?
> > >
> > > Sounds fine to me.
> > >
> >
> > David,
> >
> > Ok. :)
> >
> > If you transfer DBD::Pg over, I wiill try to get those releases up
> > tonight.
> >
> > Thanks,
> >
> > Rudy
> >
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 04:42 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rudy Lippan <rlippan@remotelinux.com>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 2003-03-27 04:42 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
Oops, too late. 1.22 packaged and released on gborg, soon CPAN. Feel
free to start on 1.30 and we can take our time. There were enough fixes
in CVS head that we needed to get a release out.
---------------------------------------------------------------------------
Rudy Lippan wrote:
> On Wed, 26 Mar 2003, Bruce Momjian wrote:
>
> > OK, so you are saying that the code as exists now in CVS is ready for
> > release, and once we release, you want to add a lot of stuff, right?
> > And there is nothing that needs work _before_ we do a release?
>
> Bruce,
>
> 1.21 + UTF-8 patch should be ready to be released as 1.22. We can skip
> putting up a 1.22 and jump right to 1.30 alpha if we don't see a need for
> getting out the UTF patch? I am easy on this point. So do we want a 1.22
> or do we want to jump right to a 1.30 alpha?
>
>
> The 'a lot of stuff' is already in CVS on the 1_30 branch. I put it there
> because I thought we were going to be releasing a 1.22 for basic UTF
> support, but since then CVS head has gathered a few other patches that are
> not ready for release :(
>
> What I am planing on doing is copying 1_30 over cvs head, making an alpha
> release based on that, and then merging all of the patches that were added
> since 1.21. (And all new patches against CVS head will be easier to
> apply).
>
>
> The patch that is on the 1_30 branch is here:
> ftp://gborg.postgresql.org/pub/dbdpg/1/dbd_pg.patch and I think it would
> be much easier to merge a few minor patches rather than the other way
> around :)
>
> Thoughs?
>
>
> Rudy
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 04:46 David Wheeler <david@wheeler.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: David Wheeler @ 2003-03-27 04:46 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Rudy Lippan <rlippan@remotelinux.com>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
On Wednesday, March 26, 2003, at 10:40 PM, Bruce Momjian wrote:
> OK, release DBD-pg 1.22 uploaded to gborg:
I put it on CPAN. Feel free to announce.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-03-27 05:24 Rudy Lippan <rlippan@remotelinux.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Rudy Lippan @ 2003-03-27 05:24 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
On Wed, 26 Mar 2003, Bruce Momjian wrote:
>
> Oops, too late. 1.22 packaged and released on gborg, soon CPAN. Feel
> free to start on 1.30 and we can take our time. There were enough fixes
> in CVS head that we needed to get a release out.
>
Yeah, there were some bugs in the patches -- the array one will erase
the array that you pass in... But oh well... Maybe noone will notice ;)
Anyway, I will get 1.30 up onto CVS head on the morrow (well later today,
now), and we can start working form there ( And 1.30 fixes those pesky
segfaults that got commented in 1.22 :) Although, it might add others :( )
Later,
Rudy
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Prepare and prepare ?
@ 2003-05-26 04:31 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Rudy Lippan <rlippan@remotelinux.com>
1 sibling, 0 replies; 27+ messages in thread
From: Bruce Momjian @ 2003-05-26 04:31 UTC (permalink / raw)
To: Rudy Lippan <rlippan@remotelinux.com>; +Cc: David Wheeler <david@wheeler.net>; Dominic Mitchell <dom@semantico.com>; pgsql-interfaces; dbi-dev@perl.org
Rudy, where are we on the release of DBD:pg withs your patches? Are
they ready to go?
---------------------------------------------------------------------------
Rudy Lippan wrote:
> On Wed, 26 Mar 2003, Bruce Momjian wrote:
>
> > OK, so you are saying that the code as exists now in CVS is ready for
> > release, and once we release, you want to add a lot of stuff, right?
> > And there is nothing that needs work _before_ we do a release?
>
> Bruce,
>
> 1.21 + UTF-8 patch should be ready to be released as 1.22. We can skip
> putting up a 1.22 and jump right to 1.30 alpha if we don't see a need for
> getting out the UTF patch? I am easy on this point. So do we want a 1.22
> or do we want to jump right to a 1.30 alpha?
>
>
> The 'a lot of stuff' is already in CVS on the 1_30 branch. I put it there
> because I thought we were going to be releasing a 1.22 for basic UTF
> support, but since then CVS head has gathered a few other patches that are
> not ready for release :(
>
> What I am planing on doing is copying 1_30 over cvs head, making an alpha
> release based on that, and then merging all of the patches that were added
> since 1.21. (And all new patches against CVS head will be easier to
> apply).
>
>
> The patch that is on the 1_30 branch is here:
> ftp://gborg.postgresql.org/pub/dbdpg/1/dbd_pg.patch and I think it would
> be much easier to merge a few minor patches rather than the other way
> around :)
>
> Thoughs?
>
>
> Rudy
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 27+ messages in thread
end of thread, other threads:[~2003-05-26 04:31 UTC | newest]
Thread overview: 27+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-01-23 14:34 Prepare and prepare ? Kaare Rasmussen <kar@kakidata.dk>
2003-01-24 01:31 ` David Wheeler <david@wheeler.net>
2003-02-05 03:46 ` Rudy Lippan <rlippan@remotelinux.com>
2003-02-12 03:51 Re: Prepare and prepare ? Rudy Lippan <rlippan@remotelinux.com>
2003-02-12 15:51 ` David Wheeler <david@wheeler.net>
2003-02-13 00:42 ` Rudy Lippan <rlippan@remotelinux.com>
2003-02-13 01:30 ` David Wheeler <david@wheeler.net>
2003-02-13 01:49 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-02-13 02:40 ` David Wheeler <david@wheeler.net>
2003-02-13 03:56 ` Rudy Lippan <rlippan@remotelinux.com>
2003-02-13 03:32 ` Rudy Lippan <rlippan@remotelinux.com>
2003-02-13 06:16 ` David Wheeler <david@wheeler.net>
2003-02-15 15:46 Re: Prepare and prepare ? Rudy Lippan <rlippan@remotelinux.com>
2003-02-15 16:14 ` David Wheeler <david@wheeler.net>
2003-03-14 20:25 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-26 04:29 ` Rudy Lippan <rlippan@remotelinux.com>
2003-03-26 23:03 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-27 01:47 ` Rudy Lippan <rlippan@remotelinux.com>
2003-03-27 01:49 ` David Wheeler <david@wheeler.net>
2003-03-27 02:26 ` Rudy Lippan <rlippan@remotelinux.com>
2003-03-27 03:05 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-27 04:39 ` Rudy Lippan <rlippan@remotelinux.com>
2003-03-27 04:42 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-27 05:24 ` Rudy Lippan <rlippan@remotelinux.com>
2003-05-26 04:31 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-27 04:40 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-03-27 04:46 ` David Wheeler <david@wheeler.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox