Thread: Prepare and prepare ?
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
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]
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
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_queryn" ($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 timeexecute 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 functionsswiped 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, sodecide exactly how to do this and how to get prepares of INSERT statements to work? Move prepqre to execute and buildlist column list in bind_param? Add attributes to prepare to identify the columns and serverside prepare if theyexist? 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 quotefunction. This will take care of broken chopblanks and pg_bool_tf (pass the quote/dequote options struct to functionquote/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
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]
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
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]
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, Pennsylvania19073
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]
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
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
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]
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
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]
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, Pennsylvania19073
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.
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,
Pennsylvania19073
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.
> >
> >
>
>
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]
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
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, Pennsylvania19073
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
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, Pennsylvania19073
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, Pennsylvania19073
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]
We have just released DBD-pg 1.22. Here are the changes:
1.22 Wed Mar 26 22:33:44 EST 2003
- Win32 compile fix for snprintf [Joe Spears] - Fix memory allocation problem in bytea escaping [Barrie
Slaymaker] - Add utf8 support [Dominic Mitchell <dom@semantico.com>] - Transform Perl arrays into PostgreSQL
arrays[Alexey Slynko] - Fix for foreign_key_info() [Keith Keller] - Fix PG_TEXT parameter binding -
Doccleanups [turnstep] - Fix warning from func($table, 'table_attributes') [turnstep] - Added suppport for
schemas[turnstep] - Fix binary to a bytea field conversion [Chris Dunlop <chris@onthe.net.au>]
-- 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,
Pennsylvania19073
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
Trying to install on Mac OSX 10.2.4 Everything all compiles ok, but all the tests fail with dyld: /usr/bin/perl Undefined symbols: _is_utf8_string Anyone know what this means? Perl 5 5.6.0 DBI module 1.35 PostgreSQL 7.3.2 Test::Simple 0.47 Thanks for any help Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
What version of perl do you have? I have 5.005_03, and others have 5.6,
and both seem to work. The current test in dbdimp.c is:#ifdef SvUTF8_off if (imp_dbh->pg_enable_utf8) {
SvUTF8_off(sv); /* XXX Is this all the character data types? */ if (18 == type || 25 == type || 1042
==type|| 1043 == type) { if (is_high_bit_set(val) && is_utf8_string(val, val_len)) SvUTF8_on(sv);
} }#endif
Maybe that isn't the right test --- maybe you have a version of perl
that passes the #ifdef test, but doesn't have is_utf8_string().
---------------------------------------------------------------------------
Adam Witney wrote:
>
> Trying to install on Mac OSX 10.2.4
>
> Everything all compiles ok, but all the tests fail with
>
> dyld: /usr/bin/perl Undefined symbols: _is_utf8_string
>
> Anyone know what this means?
>
> Perl 5 5.6.0
> DBI module 1.35
> PostgreSQL 7.3.2
> Test::Simple 0.47
>
> Thanks for any help
>
> Adam
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> ---------------------------(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,
Pennsylvania19073
On 28/3/03 3:58 pm, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> What version of perl do you have? I have 5.005_03, and others have 5.6,
> and both seem to work. The current test in dbdimp.c is:
>
> #ifdef SvUTF8_off
> if (imp_dbh->pg_enable_utf8) {
> SvUTF8_off(sv);
> /* XXX Is this all the character data types? */
> if (18 == type || 25 == type || 1042 ==type || 1043 == type) {
> if (is_high_bit_set(val) && is_utf8_string(val, val_len))
> SvUTF8_on(sv);
> }
> }
> #endif
>
> Maybe that isn't the right test --- maybe you have a version of perl
> that passes the #ifdef test, but doesn't have is_utf8_string().
>
I have perl 5.6.0. I don't know if it has is_utf8_string()... Where would I
look for this?
The output of perl -V if this helps
[mrc1-003:] adam% perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=darwin, osvers=6.0,
archname=darwin uname='darwin fisheye 6.0 darwin kernel version 5.2: mon jun 17 09:55:14
pdt 2002; root:xnu-201-14.rootsxnu-201-14.objrelease_ppc power macintosh
powerpc ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=' hint=recommended, useposix=true,
d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef
uselongdouble=undefusesocks=undef Compiler: cc='cc', optimize='-Os', gccversion=Apple cpp-precomp 6.14 cppflags='-g
-pipe-pipe -fno-common -no-cpp-precomp -flat_namespace
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing' ccflags ='-g -pipe -pipe -fno-common -no-cpp-precomp -flat_namespace
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4,
longsize=4,ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long',ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =''
libpth=/usr/lib libs=-lm -lc libc=/System/Library/Frameworks/System.framework/System, so=dylib,
useshrplib=true, libperl=libperl.dylib Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags='
' cccdlflags=' ', lddlflags='-bundle -flat_namespace -undefined suppress'
Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at Jul
142002 04:04:33 %ENV: PERL5LIB="/sw/lib/perl5" @INC: /sw/lib/perl5/darwin /sw/lib/perl5
/System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin /Library/Perl /Library/Perl
/Network/Library/Perl/darwin /Network/Library/Perl /Network/Library/Perl .
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
On Saturday 29 March 2003 15:56, Adam Witney wrote:
> On 28/3/03 3:58 pm, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
> > What version of perl do you have? I have 5.005_03, and others have 5.6,
> > and both seem to work. The current test in dbdimp.c is:
> >
> > #ifdef SvUTF8_off
> > if (imp_dbh->pg_enable_utf8) {
> > SvUTF8_off(sv);
> > /* XXX Is this all the character data types? */
> > if (18 == type || 25 == type || 1042 ==type || 1043 == type) {
> > if (is_high_bit_set(val) && is_utf8_string(val, val_len))
> > SvUTF8_on(sv);
> > }
> > }
> > #endif
> >
> > Maybe that isn't the right test --- maybe you have a version of perl
> > that passes the #ifdef test, but doesn't have is_utf8_string().
>
> I have perl 5.6.0. I don't know if it has is_utf8_string()... Where would I
> look for this?
I'm fuzzy on the details but ISTR Perl 5.6.0 was not one of Perl's better
releases and was replaced fairly quickly with 5.6.1. A bit of googling
returns is_utf8_string() together with 5.6.1 but no references to 5.6. This
is not scientific evidence though.
Can you do "perldoc perlapi" with 5.6.0? If so the presence / absence
of is_utf8_string() should solve the problem.
Ian Barwick
barwick@gmx.net
On 30/3/03 11:28 pm, "Ian Barwick" <barwick@gmx.net> wrote:
> On Saturday 29 March 2003 15:56, Adam Witney wrote:
>> On 28/3/03 3:58 pm, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>>> What version of perl do you have? I have 5.005_03, and others have 5.6,
>>> and both seem to work. The current test in dbdimp.c is:
>>>
>>> #ifdef SvUTF8_off
>>> if (imp_dbh->pg_enable_utf8) {
>>> SvUTF8_off(sv);
>>> /* XXX Is this all the character data types? */
>>> if (18 == type || 25 == type || 1042 ==type || 1043 == type) {
>>> if (is_high_bit_set(val) && is_utf8_string(val, val_len))
>>> SvUTF8_on(sv);
>>> }
>>> }
>>> #endif
>>>
>>> Maybe that isn't the right test --- maybe you have a version of perl
>>> that passes the #ifdef test, but doesn't have is_utf8_string().
>>
>> I have perl 5.6.0. I don't know if it has is_utf8_string()... Where would I
>> look for this?
>
> I'm fuzzy on the details but ISTR Perl 5.6.0 was not one of Perl's better
> releases and was replaced fairly quickly with 5.6.1. A bit of googling
> returns is_utf8_string() together with 5.6.1 but no references to 5.6. This
> is not scientific evidence though.
>
> Can you do "perldoc perlapi" with 5.6.0? If so the presence / absence
> of is_utf8_string() should solve the problem.
Yep, there is no trace of is_utf8_string() in perldoc perlapi for 5.6.0
Does this mean that my only option is to upgrade perl? Or will the module
still work without it?
Thanks for your help
adam
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
On Mon, 31 Mar 2003, Adam Witney wrote: > Yep, there is no trace of is_utf8_string() in perldoc perlapi for 5.6.0 > That sounds about right. > Does this mean that my only option is to upgrade perl? Or will the module > still work without it? You can either upgrade perl to 5.6.1 or, if you don't want to upgrade perl, you can dike out the section of code between the #ifdef and #endif and then it should work (might fail some UTF-8 test). I would recommed upgrading perl, however. -r
> On Mon, 31 Mar 2003, Adam Witney wrote: > >> Yep, there is no trace of is_utf8_string() in perldoc perlapi for 5.6.0 >> > > That sounds about right. > >> Does this mean that my only option is to upgrade perl? Or will the module >> still work without it? > > You can either upgrade perl to 5.6.1 or, if you don't want to upgrade > perl, you can dike out the section of code between the #ifdef and #endif > and then it should work (might fail some UTF-8 test). I would recommed > upgrading perl, however. Ok, I have upgraded to perl 5.6.1, but now make test gives this ..... t/03bind............ok t/04execute.........ok 9/13*** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed object - object was probably modified after being freed; break at szone_error *** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed object - object was probably modified after being freed; break at szone_error t/04execute.........dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 10-13 Failed 4/13 tests, 69.23% okay t/05fetch...........ok, 3/10 skipped: need Encode module for unicode tests t/06disconnect......ok t/07reuse...........ok t/08txn.............ok t/09autocommit......ok t/11quoting.........ok t/12placeholders....ok t/13pgtype..........ok t/15funct...........ok 4/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 5/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 6/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 808. t/15funct...........ok 25/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 26/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 28/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 605. t/15funct...........ok 31/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 32/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 33/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 34/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 35/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 36/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 701. t/15funct...........ok 37/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 38/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 39/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 40/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 41/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 42/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 43/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 44/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 45/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 46/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 47/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 48/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 49/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 50/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 203. t/15funct...........ok 53/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 291. t/15funct...........ok 54/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 291. t/15funct...........ok 56/59Argument "7.3.2" isn't numeric in numeric lt (<) at blib/lib/DBD/Pg.pm line 291. t/15funct...........ok, 7/59 skipped: various reasons t/99cleanup.........ok Failed Test Status Wstat Total Fail Failed List of Failed ---------------------------------------------------------------------------- ---- t/04execute.t 0 11 13 4 30.77% 10-13 10 subtests skipped. Failed 1/17 test scripts, 94.12% okay. 4/186 subtests failed, 97.85% okay. make: *** [test_dynamic] Error 255 Any ideas whats happening now? Thanks Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Tue, 8 Apr 2003, Adam Witney wrote: > ..... > t/03bind............ok > t/04execute.........ok 9/13*** malloc[20356]: error for object 0x235c20: > Incorrect checksum for freed object - object was probably modified after > being freed; break at szone_error > *** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed > object - object was probably modified after being freed; break at > szone_error > t/04execute.........dubious > Test returned status 0 (wstat 11, 0xb) > DIED. FAILED tests 10-13 > Failed 4/13 tests, 69.23% okay I do not like the looks of this. Did this test fail with DBD::Pg 1.21? > at blib/lib/DBD/Pg.pm line 291. > t/15funct...........ok 56/59Argument "7.3.2" isn't numeric in numeric lt (<) > at blib/lib/DBD/Pg.pm line 291. I ran into this on my system also. There is a if $version >7.x where I can't remember what x is. Anyway the regex that pulls version gets "7.3.2" which can't be used as a number so perl warns you. I will write up a patch for this later today. Grrr. -r
On 8/4/03 2:32 pm, "Rudy Lippan" <rlippan@remotelinux.com> wrote: > On Tue, 8 Apr 2003, Adam Witney wrote: > >> ..... >> t/03bind............ok >> t/04execute.........ok 9/13*** malloc[20356]: error for object 0x235c20: >> Incorrect checksum for freed object - object was probably modified after >> being freed; break at szone_error >> *** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed >> object - object was probably modified after being freed; break at >> szone_error >> t/04execute.........dubious >> Test returned status 0 (wstat 11, 0xb) >> DIED. FAILED tests 10-13 >> Failed 4/13 tests, 69.23% okay > > I do not like the looks of this. Did this test fail with DBD::Pg 1.21? Just downloaded, built and tested DBD-Pg-1.21 with no problems. >> at blib/lib/DBD/Pg.pm line 291. >> t/15funct...........ok 56/59Argument "7.3.2" isn't numeric in numeric lt (<) >> at blib/lib/DBD/Pg.pm line 291. > > I ran into this on my system also. There is a if $version >7.x where I > can't remember what x is. Anyway the regex that pulls version gets "7.3.2" > which can't be used as a number so perl warns you. I will write up a > patch for this later today. Grrr. I had a look myself... Its this one $version < 7.3 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Ok, I have upgraded to perl 5.6.1, but now make test gives this I am not sure about the malloc errors, but the "isn't numeric" errors should be fixed by grabbing an updated version of DBD::Pg. By the way, the latest stable version of perl is 5.8.0. You may want to consider jumping to that as long as you are upgrading. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200304080926 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+ks6evJuQZxSWSsgRAmcLAKCdRHIB+XGQH/VGUmtEK8vwFiuYkQCfV/CE 9Ga23giFd4I+iZ0pzF1XvvM= =jzS7 -----END PGP SIGNATURE-----
On Tue, 8 Apr 2003, Adam Witney wrote: > >> t/03bind............ok > >> t/04execute.........ok 9/13*** malloc[20356]: error for object 0x235c20: > >> Incorrect checksum for freed object - object was probably modified after > >> being freed; break at szone_error > >> *** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed > >> object - object was probably modified after being freed; break at > >> szone_error > >> t/04execute.........dubious > >> Test returned status 0 (wstat 11, 0xb) > >> DIED. FAILED tests 10-13 > >> Failed 4/13 tests, 69.23% okay > > > > I do not like the looks of this. Did this test fail with DBD::Pg 1.21? > > Just downloaded, built and tested DBD-Pg-1.21 with no problems. > I don't see why 1.21 should work while 1.22 failes, so all I can say is If 1.21 works, use it. If you see this 1.21, you might want to try what is in CVS because much of the prepare, quoting and execute code was rewritten and might have fixed the issue. > > I ran into this on my system also. There is a if $version >7.x where I > > can't remember what x is. Anyway the regex that pulls version gets "7.3.2" > > which can't be used as a number so perl warns you. I will write up a > > patch for this later today. Grrr. > > I had a look myself... Its this one > > $version < 7.3 > Yup, looks like someone put in a patch to fix that already. -r
On 9/4/03 4:26 am, "Rudy Lippan" <rlippan@remotelinux.com> wrote: > On Tue, 8 Apr 2003, Adam Witney wrote: > >>>> t/03bind............ok >>>> t/04execute.........ok 9/13*** malloc[20356]: error for object 0x235c20: >>>> Incorrect checksum for freed object - object was probably modified after >>>> being freed; break at szone_error >>>> *** malloc[20356]: error for object 0x235c20: Incorrect checksum for freed >>>> object - object was probably modified after being freed; break at >>>> szone_error >>>> t/04execute.........dubious >>>> Test returned status 0 (wstat 11, 0xb) >>>> DIED. FAILED tests 10-13 >>>> Failed 4/13 tests, 69.23% okay >>> >>> I do not like the looks of this. Did this test fail with DBD::Pg 1.21? >> >> Just downloaded, built and tested DBD-Pg-1.21 with no problems. >> > > I don't see why 1.21 should work while 1.22 failes, so all I can say is > If 1.21 works, use it. If you see this 1.21, you might want to > try what is in CVS because much of the prepare, quoting and execute code > was rewritten and might have fixed the issue. The only problem is I wanted to try out the "Transform Perl arrays into PostgreSQL arrays" feature in 1.22 Ok, so have tried the make test again and now I get this t/04execute.........ok 9/13Attempt to free non-existent shared string at t/04execute.t line 87. t/04execute.........dubious Test returned status 0 (wstat 10, 0xa) DIED. FAILED tests 10-13 Failed 4/13 tests, 69.23% okay Have been building apache and mod_perl in between (presumably irrelevent for this?) and have of course had several restarts of the machine (laptop)... So apart from this nothing else should have changed. Does this help finding the problem? Thanks adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
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, Pennsylvania19073
On Mon, 26 May 2003, Bruce Momjian wrote: > Rudy, where are we on the release of DBD:pg withs your patches? Are > they ready to go? I spun an ALPHA copy of DBD::Pg. So much has changed in there that I am sure something is broken for someone; therefore, I think we should let people hammer on it for a few days before making an official release. I put the alpha up here: http://www.remotelinux.com/rlippan/DBD-Pg-1.30_1.tar.gz And for anyone who is interested here is the change log: - $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_queryn" ($1, $2, ... $n, $n+1)' for DBD::Pg's execute. -- Currently disabled until PREPARE works a little better - Allows the use of :n and :foo bind params. So: (SELECT * FROM foo where 1 = :this and 2 = :that) will now work. - Complains on execute when unbound bind params are submitted (instead of defaulting to NULL) - Switched over to use driver.xst. - pg_error() only removes \n's don't truncate message onfirst \n - fixed statement scan problem where the preparse of "SELECT foo[3:33] from bar" was scanning :33 as aplaceholder - moved the quoting of bind values out of execute() and into bind -- as there is no need to requote thevalue every time execute is called. - :veryverylongplaceholdername == Long walk. Sort pier -- fixed. - quote()is now in C and uses same code as bind_param. - 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) - bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is PGBOOLOID. - fixed many heap buffer overruns.
On Thu, May 29, 2003 at 10:00:21AM +0100, Dominic Mitchell wrote:
>
> One more thing for the change log: notice messages generated by the
> database now use the perl warning mechanism instead of going to stderr,
> so they can be trapped if needed.
Hopefully implemented as
if (DBIc_WARN(imp_xxh)) warn("...", ...)
The $h->{Warn} attribute defaults to true. Can be useful to silence
warnings for a handle without having to play games with $SIG{__WARN__}.
Tim.
Tim Bunce wrote:
> On Thu, May 29, 2003 at 10:00:21AM +0100, Dominic Mitchell wrote:
>
>>One more thing for the change log: notice messages generated by the
>>database now use the perl warning mechanism instead of going to stderr,
>>so they can be trapped if needed.
>
>
> Hopefully implemented as
>
> if (DBIc_WARN(imp_xxh))
> warn("...", ...)
>
> The $h->{Warn} attribute defaults to true. Can be useful to silence
> warnings for a handle without having to play games with $SIG{__WARN__}.
See, I told you I wasn't an XS guru. :-)
Actually, I looked at this, but my limited C and DBI skills couldn't
work out a) what the required handle was (probably dbh) and b) how to
pass that into the PQsetNoticeProcessor function as data and get it out
again.
I'll happily take another look though, now that it's been brought up as
desirable.
-Dom (time to reread K&R, methinks)
On Fri, May 30, 2003 at 10:20:11AM +0100, Dominic Mitchell wrote:
> Tim Bunce wrote:
> >On Thu, May 29, 2003 at 10:00:21AM +0100, Dominic Mitchell wrote:
> >
> >>One more thing for the change log: notice messages generated by the
> >>database now use the perl warning mechanism instead of going to stderr,
> >>so they can be trapped if needed.
> >
> >
> >Hopefully implemented as
> >
> > if (DBIc_WARN(imp_xxh))
> > warn("...", ...)
> >
> >The $h->{Warn} attribute defaults to true. Can be useful to silence
> >warnings for a handle without having to play games with $SIG{__WARN__}.
>
> See, I told you I wasn't an XS guru. :-)
>
> Actually, I looked at this, but my limited C and DBI skills couldn't
> work out a) what the required handle was (probably dbh)
Just whatever handle was used to call the method that's generating the warning.
> and b) how to pass that into the PQsetNoticeProcessor function as data
> and get it out again.
Ah, different issue. For that I'd say if DBIc_WARN(imp_xxh) isn't true
then disable the PQsetNoticeProcessor function.
> I'll happily take another look though, now that it's been brought up as
> desirable.
Actually I'd misunderstood the circumstances of the warn (not reading
your message carefully enough). For notice messages generated by
the database server they'll soon(ish) be a $h->{HandleEvent} = sub { ... }
hook that should be used.
But that'll bring you back to needing some way for the PQsetNoticeProcessor
function to get at the handle data it'll need to pass to the HandleEvent
hook. The PQsetNoticeProcessor API ought to allow you to some way to do that.
Tim.
Tim Bunce wrote:
> On Fri, May 30, 2003 at 10:20:11AM +0100, Dominic Mitchell wrote:
>>See, I told you I wasn't an XS guru. :-)
>>
>>Actually, I looked at this, but my limited C and DBI skills couldn't
>>work out a) what the required handle was (probably dbh)
>
>
> Just whatever handle was used to call the method that's generating the warning.
>
>
>>and b) how to pass that into the PQsetNoticeProcessor function as data
>>and get it out again.
>
>
> Ah, different issue. For that I'd say if DBIc_WARN(imp_xxh) isn't true
> then disable the PQsetNoticeProcessor function.
Well, we're calling PQsetNoticeProcessor[1], from inside dbd_db_login,
so I should be able to pass in imp_dbh as the "arg" argument. The bit
that I wasn't sure about before was what to cast it to in order to
retrieve it from a void *.
>>I'll happily take another look though, now that it's been brought up as
>>desirable.
>
>
> Actually I'd misunderstood the circumstances of the warn (not reading
> your message carefully enough). For notice messages generated by
> the database server they'll soon(ish) be a $h->{HandleEvent} = sub { ... }
> hook that should be used.
How will that work? Is that for any sort of asynchronous message from
the database?
> But that'll bring you back to needing some way for the PQsetNoticeProcessor
> function to get at the handle data it'll need to pass to the HandleEvent
> hook. The PQsetNoticeProcessor API ought to allow you to some way to do that.
It does, I just couldn't figure it out in the 30 minutes I spent looking
at it. I need to go back and spend more time with the docs and less
being lazy. :-)
-Dom
[1] Damn mozilla for not being emacs[2]. I want dynamic-abbrevs!
[2] Or vim. That does it too.
On Fri, May 30, 2003 at 03:13:04PM +0100, Dominic Mitchell wrote:
> Tim Bunce wrote:
> >On Fri, May 30, 2003 at 10:20:11AM +0100, Dominic Mitchell wrote:
> >>See, I told you I wasn't an XS guru. :-)
> >>
> >>Actually, I looked at this, but my limited C and DBI skills couldn't
> >>work out a) what the required handle was (probably dbh)
> >
> >Just whatever handle was used to call the method that's generating the
> >warning.
> >
> >>and b) how to pass that into the PQsetNoticeProcessor function as data
> >>and get it out again.
> >
> >
> >Ah, different issue. For that I'd say if DBIc_WARN(imp_xxh) isn't true
> >then disable the PQsetNoticeProcessor function.
>
> Well, we're calling PQsetNoticeProcessor[1], from inside dbd_db_login,
> so I should be able to pass in imp_dbh as the "arg" argument. The bit
> that I wasn't sure about before was what to cast it to in order to
> retrieve it from a void *.
You could always cast it to a void * :-)
> >Actually I'd misunderstood the circumstances of the warn (not reading
> >your message carefully enough). For notice messages generated by
> >the database server they'll soon(ish) be a $h->{HandleEvent} = sub { ... }
> >hook that should be used.
>
> How will that work? Is that for any sort of asynchronous message from
> the database?
That kind of thing, yes, plus 'success with info' and anything else
a driver wants to comminucate back to an app 'out of band'. The
tricky part will be categorizing the types of events to make it
usefully portable. But I don't want to start that thread just yet,
so ignore me!
> >But that'll bring you back to needing some way for the PQsetNoticeProcessor
> >function to get at the handle data it'll need to pass to the HandleEvent
> >hook. The PQsetNoticeProcessor API ought to allow you to some way to do
> >that.
>
> It does, I just couldn't figure it out in the 30 minutes I spent looking
> at it. I need to go back and spend more time with the docs and less
> being lazy. :-)
>
> -Dom
>
> [1] Damn mozilla for not being emacs[2]. I want dynamic-abbrevs!
> [2] Or vim. That does it too.
I use mutt and so edit messages in vim. Works well for me.
Tim.
On Thursday, May 29, 2003, at 01:57 AM, Rudy Lippan wrote: > On Mon, 26 May 2003, Bruce Momjian wrote: > >> Rudy, where are we on the release of DBD:pg withs your patches? Are >> they ready to go? > > > I spun an ALPHA copy of DBD::Pg. So much has changed in there that I am > sure something is broken for someone; therefore, I think we should let > people hammer on it for a few days before making an official release. > > I put the alpha up here: > http://www.remotelinux.com/rlippan/DBD-Pg-1.30_1.tar.gz Nice, thanks for this, Rudy. > And for anyone who is interested here is the change log: > > - $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. -- Currently > disabled > until PREPARE works a little better Pity. Do you know if it will work as well as you need in 7.4? Have you tested it with the latest from CVS? I think that it is close-ish to done, so now would be the time to get in any requests for fixes. > - Allows the use of :n and :foo bind params. So: (SELECT * FROM foo > where > 1 = :this and 2 = :that) will now work. > - Complains on execute when unbound bind params are submitted > (instead > of > defaulting to NULL) Ah, good! > - Switched over to use driver.xst. About time we did this! > - pg_error() only removes \n's don't truncate message on first \n Heh, funny. If we don't release 1.30 with all your changes soon, it might be worth it to backport this fix. > - fixed statement scan problem where the preparse of > "SELECT foo[3:33] from bar" was scanning :33 as a placeholder > - 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. rudy++ > - :veryverylongplaceholdername == Long walk. Sort pier -- fixed. > - quote() is now in C and uses same code as bind_param. > - 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) Good, nice to have all this centralized. > - bind_param() will convert from 1,0 to TRUE/FALSE when pg_type is > PGBOOLOID. Nice. > - fixed many heap buffer overruns. Thanks Rudy, sounds great! David -- David Wheeler AIM: dwTheory david@kineticode.com ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: Theory@jabber.org Kineticode. Setting knowledge in motion.[sm]
Rudy Lippan wrote: > On Mon, 26 May 2003, Bruce Momjian wrote: > > >>Rudy, where are we on the release of DBD:pg withs your patches? Are >>they ready to go? > > > > I spun an ALPHA copy of DBD::Pg. So much has changed in there that I am > sure something is broken for someone; therefore, I think we should let > people hammer on it for a few days before making an official release. > > I put the alpha up here: > http://www.remotelinux.com/rlippan/DBD-Pg-1.30_1.tar.gz > > > And for anyone who is interested here is the change log: One more thing for the change log: notice messages generated by the database now use the perl warning mechanism instead of going to stderr, so they can be trapped if needed. -Dom