Release of DBD-pg 1.22

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(at)kineticode(dot)com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)kineticode(dot)com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)kineticode(dot)com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)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(at)semantico(dot)com>]
- Transform Perl arrays into PostgreSQL arrays [Alexey Slynko]
- Fix for foreign_key_info() [Keith Keller]
- Fix PG_TEXT parameter binding
- Doc cleanups [turnstep]
- Fix warning from func($table, 'table_attributes') [turnstep]
- Added suppport for schemas [turnstep]
- Fix binary to a bytea field conversion [Chris Dunlop <chris(at)onthe(dot)net(dot)au>]

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On 28/3/03 3:58 pm, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)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=undef usesocks=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 14 2002 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(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)net

On 30/3/03 11:28 pm, "Ian Barwick" <barwick(at)gmx(dot)net> wrote:

> On Saturday 29 March 2003 15:56, Adam Witney wrote:
>> On 28/3/03 3:58 pm, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)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.

-----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(at)turnstep(dot)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?

> 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

> 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.

This is DBD-Pg-1.22, do you mean newer than that?

> 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.

The only thing is that I have heard suggestions that replacing the stock
perl on OS X with 5.8 can cause problems with certain system functions

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On 8/4/03 2:32 pm, "Rudy Lippan" <rlippan(at)remotelinux(dot)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

>> 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.

> This is DBD-Pg-1.22, do you mean newer than that?

Yes, sorry I was not clear. The latest CVS version should cleanly work
around the versioning problem. In particular, you should be able to
replace just the file "Pg.pm" to fix that problem:

http://gborg.postgresql.org/project/dbdpg/cvs/cvs.php/dbdpg

>> 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.

> The only thing is that I have heard suggestions that replacing the stock
> perl on OS X with 5.8 can cause problems with certain system functions

Forgot about the OS X factor. Nevermind. :) You want 5.6.1r2.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200304080959

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE+ktaVvJuQZxSWSsgRAmfbAKCaBsg82LsLGry5HJ+iP0qUfJtcQACfcm4C
8q0kk3kTJEZgGVz16JzW+/Q=
=3Lw2
-----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(at)remotelinux(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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_query n"
($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 on first \n
- 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.
- :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.

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

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(at)kineticode(dot)com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org
Kineticode. Setting knowledge in motion.[sm]

On Thursday, May 29, 2003, at 02:00 AM, 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.

Oh, sweet! How did you do that? I've been doing this to catch them:

<hack caveat="ugly">

open STDERR, "| perl -ne 'print unless /: NOTICE: /'"
or die "Cannot pipe STDERR: $!\n";

</hack>

Regards,

David
--
David Wheeler AIM: dwTheory
david(at)kineticode(dot)com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org
Kineticode. Setting knowledge in motion.[sm]

David Wheeler wrote:
> On Thursday, May 29, 2003, at 02:00 AM, 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.
>
>
> Oh, sweet! How did you do that? I've been doing this to catch them:
>
> <hack caveat="ugly">
>
> open STDERR, "| perl -ne 'print unless /: NOTICE: /'"
> or die "Cannot pipe STDERR: $!\n";
>
> </hack>

Just hook up the existing libpq function PQsetNoticeProcessor() to a
XS's warn in dbdimp.c. It's about 5 lines of code. I don't know
whether it's 100% correct (I'm no XS guru), but it Works For Me[tm].

-Dom

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 Thu, 29 May 2003, David Wheeler wrote:
> > 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.
>

I need to test this, I'll play with it next week.

-r

On Thu, 29 May 2003, Dominic Mitchell wrote:
> >
> > 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.
>
Added on my system.. I will check it in on Mondy.

-r

> -Dom
>
>

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.

Rudy Lippan <rlippan(at)remotelinux(dot)com> writes:
> On Thu, 29 May 2003, David Wheeler wrote:
>>>> 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.

> I need to test this, I'll play with it next week.

It *is* done. The window for offering any feedback is shrinking fast,
so I'd definitely encourage you to look at it ASAP.

regards, tom lane