agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedPatch for DBD::Pg pg_relcheck problem
22+ messages / 6 participants
[nested] [flat]
* Patch for DBD::Pg pg_relcheck problem
@ 2002-12-09 15:31 Ian Barwick <barwick@gmx.net>
0 siblings, 1 reply; 22+ messages in thread
From: Ian Barwick @ 2002-12-09 15:31 UTC (permalink / raw)
To: dbi-dev@perl.org; pgsql-interfaces@postgresql.org
Attached is a patch against DBD::Pg 1.20 which
fixes the driver-specific function 'table_attributes'
for use with PostgreSQL 7.3 while maintaining
backwards compatibility with older PostgreSQL
versions.
To avoid voodoo with PostgreSQL version numbers
a check is made whether pg_relcheck exists and
the appropriate query (either 7.3 or pre 7.3)
executed. Tested with 7.3 and 7.1.3.
This is hopefully a one off problem requiring this
kind of check. I haven't had a chance to look at
every function in Pg.pm, but it seems this is the
only one "broken" by 7.3.
Comments, corrections etc. welcome!
Ian Barwick
barwick@gmx.net
Attachments:
[text/x-diff] Pg.patch (781B, ../../200212091631.00125.barwick@gmx.net/2-Pg.patch)
download | inline diff:
619c619,627
< my ($constraint) = $dbh->selectrow_array("select rcsrc from pg_relcheck where rcname = '${table}_$col_name'");
---
> # Note: as of PostgreSQL 7.3 pg_relcheck has been replaced
> # by pg_constraint. To maintain compatibility, check whether
> # pg_relcheck exists and execute the appropriate query.
>
> my ($pre73) = $dbh->selectrow_array("SELECT 1 FROM pg_class WHERE relname='pg_relcheck'") || 0;
> my $con_query = $pre73
> ? "SELECT rcsrc FROM pg_relcheck WHERE rcname = '${table}_$col_name'"
> : "SELECT consrc FROM pg_catalog.pg_constraint WHERE contype = 'c' AND conname = '${table}_$col_name'";
> my ($constraint) = $dbh->selectrow_array($con_query);
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-09 16:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Ian Barwick <barwick@gmx.net>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2002-12-09 16:03 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org
Ian Barwick <barwick@gmx.net> writes:
> To avoid voodoo with PostgreSQL version numbers
> a check is made whether pg_relcheck exists and
> the appropriate query (either 7.3 or pre 7.3)
> executed.
I would think that looking at version number (select version())
would be a much cleaner approach. Or do you think that direct
examination of pg_class is a version-independent operation?
This inquiry into pg_relcheck's existence is already arguably wrong
in 7.3 (since it's not taking account of which schema pg_relcheck
might be found in) and it can only go downhill in future versions.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-09 23:34 Ian Barwick <barwick@gmx.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 3 replies; 22+ messages in thread
From: Ian Barwick @ 2002-12-09 23:34 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org
On Monday 09 December 2002 17:03, Tom Lane wrote:
> Ian Barwick <barwick@gmx.net> writes:
> > To avoid voodoo with PostgreSQL version numbers
> > a check is made whether pg_relcheck exists and
> > the appropriate query (either 7.3 or pre 7.3)
> > executed.
>
> I would think that looking at version number (select version())
> would be a much cleaner approach. Or do you think that direct
> examination of pg_class is a version-independent operation?
No, but I was hoping it will remain stable for long enough
for what is basically a temporary work around until a revised version of
DBD::Pg can be produced. It doesn't make any more assumptions
about pg_class than are made elsewhere in the current Pg.pm.
> This inquiry into pg_relcheck's existence is already arguably wrong
> in 7.3 (since it's not taking account of which schema pg_relcheck
> might be found in) and it can only go downhill in future versions.
Doh. Knew I had to be missing something obvious. (Of course,
anyone using current DBD::Pg with 7.3 as is will have to take
extra care with system tables and schema namespaces anyway.)
So out with the candle wax and pins ;-). Am I right
in thinking that the string returned by SELECT version()
starts with the word "PostgreSQL" followed by:
a space;
a single digit indicating the major version number;
a full stop / decimal point;
a single digit indicating the minor version number;
and either "interim release" number (e.g. ".1" in the case of 7.3.1), or
"devel", "rc1" etc. ?
And that this has been true since 6.x and will continue for the forseeable
future (i.e. far far longer than the intended lifespan of attached patch)?
Ian Barwick
barwick@gmx.net
Attached: revised patch
Attachments:
[text/x-diff] Pg.patch (800B, ../../200212100034.31936.barwick@gmx.net/2-Pg.patch)
download | inline diff:
619c619,629
< my ($constraint) = $dbh->selectrow_array("select rcsrc from pg_relcheck where rcname = '${table}_$col_name'");
---
> # Note: as of PostgreSQL 7.3 pg_relcheck has been replaced
> # by pg_constraint. To maintain compatibility, check
> # version number and execute appropriate query.
>
> my ($version) = $dbh->selectrow_array("SELECT version()");
> $version =~ /^PostgreSQL (\d)\.(\d)/;
>
> my $con_query = $1.$2 < 73
> ? "SELECT rcsrc FROM pg_relcheck WHERE rcname = '${table}_$col_name'"
> : "SELECT consrc FROM pg_catalog.pg_constraint WHERE contype = 'c' AND conname = '${table}_$col_name'";
> my ($constraint) = $dbh->selectrow_array($con_query);
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-09 23:47 Tom Lane <tgl@sss.pgh.pa.us>
parent: Ian Barwick <barwick@gmx.net>
2 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2002-12-09 23:47 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org
Ian Barwick <barwick@gmx.net> writes:
> So out with the candle wax and pins ;-). Am I right
> in thinking that the string returned by SELECT version()
> starts with the word "PostgreSQL" followed by:
> a space;
> a single digit indicating the major version number;
> a full stop / decimal point;
> a single digit indicating the minor version number;
> and either "interim release" number (e.g. ".1" in the case of 7.3.1), or
> "devel", "rc1" etc. ?
I would recommend parsing it the same way pg_dump does, see
_check_database_version(). Looks like it's basically skip-11-chars-
and-sscanf. Note the lack of assumptions about numbers of digits.
In the next protocol version update (hopefully 7.4) I would like to see
the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
client automatically during connection startup and then available from a
libpq inquiry function. This would eliminate the need to call version()
explicitly and to know that you must skip "PostgreSQL " in its output.
However, it will only help for clients/libraries that are willing to
deal exclusively with 7.4-or-newer backends, so it will take a few
releases to become really useful.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-10 15:38 Ian Barwick <barwick@gmx.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 22+ messages in thread
From: Ian Barwick @ 2002-12-10 15:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org; pgsql-hackers
(crossposting to hackers)
On Tuesday 10 December 2002 00:47, Tom Lane wrote:
> In the next protocol version update (hopefully 7.4) I would like to see
> the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
> client automatically during connection startup and then available from a
> libpq inquiry function. This would eliminate the need to call version()
> explicitly and to know that you must skip "PostgreSQL " in its output.
Something along the lines of
char *PQversion(const PGconn *conn) ?
> However, it will only help for clients/libraries that are willing to
> deal exclusively with 7.4-or-newer backends, so it will take a few
> releases to become really useful.
Sounds good to me. Is it on the todo-list? (Couldn't see it there).
Ian Barwick
barwick@gmx.net
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-10 15:48 Tom Lane <tgl@sss.pgh.pa.us>
parent: Ian Barwick <barwick@gmx.net>
1 sibling, 1 reply; 22+ messages in thread
From: Tom Lane @ 2002-12-10 15:48 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org; pgsql-hackers
Ian Barwick <barwick@gmx.net> writes:
> Sounds good to me. Is it on the todo-list? (Couldn't see it there).
Probably not; Bruce for some reason has resisted listing protocol change
desires as an identifiable TODO category. There are a couple of threads
in the pghackers archives over the last year or so that discuss the
different things we want to do, though. (Improving the error-reporting
framework and fixing the COPY protocol are a couple of biggies I can
recall offhand.)
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-10 15:54 Lee Kindness <lkindness@csl.co.uk>
parent: Ian Barwick <barwick@gmx.net>
1 sibling, 1 reply; 22+ messages in thread
From: Lee Kindness @ 2002-12-10 15:54 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org, pgsql-interfaces@postgresql.org, pgsql-hackers@postgresql.org, Lee Kindness <lkindness@csl.co.uk>
Ian Barwick writes:
> On Tuesday 10 December 2002 00:47, Tom Lane wrote:
> > In the next protocol version update (hopefully 7.4) I would like to see
> > the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
> > client automatically during connection startup and then available from a
> > libpq inquiry function. This would eliminate the need to call version()
> > explicitly and to know that you must skip "PostgreSQL " in its output.
> Something along the lines of
> char *PQversion(const PGconn *conn) ?
Probably:
int PQversion(const PGconn *conn)
would be better, and easier to parse? For example the value returned
for 7.3.1 would be 7003001; for 7.4 7004000; for 101.10.2
101010002. This allows simple numerical tests...
Lee.
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-10 16:35 Ian Barwick <barwick@gmx.net>
parent: Lee Kindness <lkindness@csl.co.uk>
0 siblings, 0 replies; 22+ messages in thread
From: Ian Barwick @ 2002-12-10 16:35 UTC (permalink / raw)
To: Lee Kindness <lkindness@csl.co.uk>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-interfaces@postgresql.org; pgsql-hackers
(no followup to dbi-dev@perl.org, getting a little OT there)
On Tuesday 10 December 2002 16:54, Lee Kindness wrote:
> Ian Barwick writes:
> > Something along the lines of
> > char *PQversion(const PGconn *conn) ?
>
> Probably:
>
> int PQversion(const PGconn *conn)
>
> would be better, and easier to parse? For example the value returned
> for 7.3.1 would be 7003001; for 7.4 7004000; for 101.10.2
> 101010002. This allows simple numerical tests...
Sounds logical - I was evidently thinking in Perl ;-).
For reference pg_dump currently parses the SELECT version() string
into an integer thus:
7.2 70200
7.2.1 70201
7.3devel 70300
7.3rc1 70300
7.3.1 70301
7.3.99 70399
7.399.399 110299
101.10.2 1011002
(and just for fun:
"11i Enterprise Edition with Bells and Whistles "
returns -1 ;-)
which works with minor release numbers of 99
and below.
Ian Barwick
barwick@gmx.net
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-11 03:49 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Ian Barwick <barwick@gmx.net>
2 siblings, 0 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-11 03:49 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org
Ian, can I please have a context diff, diff -c?
---------------------------------------------------------------------------
Ian Barwick wrote:
> On Monday 09 December 2002 17:03, Tom Lane wrote:
> > Ian Barwick <barwick@gmx.net> writes:
> > > To avoid voodoo with PostgreSQL version numbers
> > > a check is made whether pg_relcheck exists and
> > > the appropriate query (either 7.3 or pre 7.3)
> > > executed.
> >
> > I would think that looking at version number (select version())
> > would be a much cleaner approach. Or do you think that direct
> > examination of pg_class is a version-independent operation?
>
> No, but I was hoping it will remain stable for long enough
> for what is basically a temporary work around until a revised version of
> DBD::Pg can be produced. It doesn't make any more assumptions
> about pg_class than are made elsewhere in the current Pg.pm.
>
> > This inquiry into pg_relcheck's existence is already arguably wrong
> > in 7.3 (since it's not taking account of which schema pg_relcheck
> > might be found in) and it can only go downhill in future versions.
>
> Doh. Knew I had to be missing something obvious. (Of course,
> anyone using current DBD::Pg with 7.3 as is will have to take
> extra care with system tables and schema namespaces anyway.)
>
> So out with the candle wax and pins ;-). Am I right
> in thinking that the string returned by SELECT version()
> starts with the word "PostgreSQL" followed by:
> a space;
> a single digit indicating the major version number;
> a full stop / decimal point;
> a single digit indicating the minor version number;
> and either "interim release" number (e.g. ".1" in the case of 7.3.1), or
> "devel", "rc1" etc. ?
> And that this has been true since 6.x and will continue for the forseeable
> future (i.e. far far longer than the intended lifespan of attached patch)?
>
>
> Ian Barwick
> barwick@gmx.net
>
> Attached: revised patch
>
>
>
>
>
>
[ Attachment, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-11 03:50 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Bruce Momjian @ 2002-12-11 03:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ian Barwick <barwick@gmx.net>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org; pgsql-hackers
Tom Lane wrote:
> Ian Barwick <barwick@gmx.net> writes:
> > Sounds good to me. Is it on the todo-list? (Couldn't see it there).
>
> Probably not; Bruce for some reason has resisted listing protocol change
> desires as an identifiable TODO category. There are a couple of threads
> in the pghackers archives over the last year or so that discuss the
> different things we want to do, though. (Improving the error-reporting
> framework and fixing the COPY protocol are a couple of biggies I can
> recall offhand.)
Listing protocol changes seemed too low-level for the TODO list, but I
have kept the email messages. Today I updated the TODO list and added a
section for them.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-11 19:44 Greg Copeland <greg@CopelandConsulting.Net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Greg Copeland @ 2002-12-11 19:44 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ian Barwick <barwick@gmx.net>; pgsql-hackers
Perhaps compression should be added to the list of protocol changes.
This way, we can allow for per packet evaluation for compression.
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
On Tue, 2002-12-10 at 21:50, Bruce Momjian wrote:
> Tom Lane wrote:
> > Ian Barwick <barwick@gmx.net> writes:
> > > Sounds good to me. Is it on the todo-list? (Couldn't see it there).
> >
> > Probably not; Bruce for some reason has resisted listing protocol change
> > desires as an identifiable TODO category. There are a couple of threads
> > in the pghackers archives over the last year or so that discuss the
> > different things we want to do, though. (Improving the error-reporting
> > framework and fixing the COPY protocol are a couple of biggies I can
> > recall offhand.)
>
> Listing protocol changes seemed too low-level for the TODO list, but I
> have kept the email messages. Today I updated the TODO list and added a
> section for them.
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: [INTERFACES] Patch for DBD::Pg pg_relcheck problem
@ 2002-12-12 00:19 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Greg Copeland <greg@CopelandConsulting.Net>
0 siblings, 0 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-12 00:19 UTC (permalink / raw)
To: Greg Copeland <greg@copelandconsulting.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Ian Barwick <barwick@gmx.net>; pgsql-hackers
Added to TODO.
---------------------------------------------------------------------------
Greg Copeland wrote:
> Perhaps compression should be added to the list of protocol changes.
> This way, we can allow for per packet evaluation for compression.
>
>
> --
> Greg Copeland <greg@copelandconsulting.net>
> Copeland Computer Consulting
>
>
> On Tue, 2002-12-10 at 21:50, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Ian Barwick <barwick@gmx.net> writes:
> > > > Sounds good to me. Is it on the todo-list? (Couldn't see it there).
> > >
> > > Probably not; Bruce for some reason has resisted listing protocol change
> > > desires as an identifiable TODO category. There are a couple of threads
> > > in the pghackers archives over the last year or so that discuss the
> > > different things we want to do, though. (Improving the error-reporting
> > > framework and fixing the COPY protocol are a couple of biggies I can
> > > recall offhand.)
> >
> > Listing protocol changes seemed too low-level for the TODO list, but I
> > have kept the email messages. Today I updated the TODO list and added a
> > section for them.
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-14 23:37 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Ian Barwick <barwick@gmx.net>
2 siblings, 3 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-14 23:37 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
Thanks. Patch applied. David, time to package up a new version of DBD:Pg?
---------------------------------------------------------------------------
Ian Barwick wrote:
> On Monday 09 December 2002 17:03, Tom Lane wrote:
> > Ian Barwick <barwick@gmx.net> writes:
> > > To avoid voodoo with PostgreSQL version numbers
> > > a check is made whether pg_relcheck exists and
> > > the appropriate query (either 7.3 or pre 7.3)
> > > executed.
> >
> > I would think that looking at version number (select version())
> > would be a much cleaner approach. Or do you think that direct
> > examination of pg_class is a version-independent operation?
>
> No, but I was hoping it will remain stable for long enough
> for what is basically a temporary work around until a revised version of
> DBD::Pg can be produced. It doesn't make any more assumptions
> about pg_class than are made elsewhere in the current Pg.pm.
>
> > This inquiry into pg_relcheck's existence is already arguably wrong
> > in 7.3 (since it's not taking account of which schema pg_relcheck
> > might be found in) and it can only go downhill in future versions.
>
> Doh. Knew I had to be missing something obvious. (Of course,
> anyone using current DBD::Pg with 7.3 as is will have to take
> extra care with system tables and schema namespaces anyway.)
>
> So out with the candle wax and pins ;-). Am I right
> in thinking that the string returned by SELECT version()
> starts with the word "PostgreSQL" followed by:
> a space;
> a single digit indicating the major version number;
> a full stop / decimal point;
> a single digit indicating the minor version number;
> and either "interim release" number (e.g. ".1" in the case of 7.3.1), or
> "devel", "rc1" etc. ?
> And that this has been true since 6.x and will continue for the forseeable
> future (i.e. far far longer than the intended lifespan of attached patch)?
>
>
> Ian Barwick
> barwick@gmx.net
>
> Attached: revised patch
>
>
>
>
>
>
[ Attachment, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-14 23:53 Ian Barwick <barwick@gmx.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 1 reply; 22+ messages in thread
From: Ian Barwick @ 2002-12-14 23:53 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
On Sunday 15 December 2002 00:37, Bruce Momjian wrote:
> Thanks. Patch applied. David, time to package up a new version of DBD:Pg?
Sorry Bruce, I've missed a couple of days through illness and
am just catching up. I think I was gong to submit a slightly different
version of the patch plus a couple of notes for the README file.
Can you hold off 24 hours or so?
Ian Barwick
barwick@gmx.net
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 01:09 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Ian Barwick <barwick@gmx.net>
0 siblings, 1 reply; 22+ messages in thread
From: Bruce Momjian @ 2002-12-15 01:09 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
Ian Barwick wrote:
> On Sunday 15 December 2002 00:37, Bruce Momjian wrote:
> > Thanks. Patch applied. David, time to package up a new version of DBD:Pg?
>
> Sorry Bruce, I've missed a couple of days through illness and
> am just catching up. I think I was gong to submit a slightly different
> version of the patch plus a couple of notes for the README file.
> Can you hold off 24 hours or so?
Until we release it, the patch can just sit in CVS. Just send over a
new version and I will back out the old one and put in the new one. I
will not do any release until you are ready.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 01:36 David Wheeler <david@wheeler.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 1 reply; 22+ messages in thread
From: David Wheeler @ 2002-12-15 01:36 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Ian Barwick <barwick@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org
On Saturday, December 14, 2002, at 03:37 PM, Bruce Momjian wrote:
> Thanks. Patch applied. David, time to package up a new version of
> DBD:Pg?
After we figure out what to do with NULLs, I think.
Best,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 01:46 Bruce Momjian <pgman@candle.pha.pa.us>
parent: David Wheeler <david@wheeler.net>
0 siblings, 1 reply; 22+ messages in thread
From: Bruce Momjian @ 2002-12-15 01:46 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Ian Barwick <barwick@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org
David Wheeler wrote:
> On Saturday, December 14, 2002, at 03:37 PM, Bruce Momjian wrote:
>
> > Thanks. Patch applied. David, time to package up a new version of
> > DBD:Pg?
>
> After we figure out what to do with NULLs, I think.
I thought you had that figured out, by flagging the param as bytea
somehow? Are you thinking of something automatic?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 01:58 David Wheeler <david@wheeler.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: David Wheeler @ 2002-12-15 01:58 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Ian Barwick <barwick@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org
On Saturday, December 14, 2002, at 05:46 PM, Bruce Momjian wrote:
> I thought you had that figured out, by flagging the param as bytea
> somehow? Are you thinking of something automatic?
No. Baldur Kristinsson points out that some people may pass a string
with NUL characters to DBD::Pg to be inserted into something other than
a bytea column. We have to figure out what to do when they do that.
Baldur Kristinsson thinks we should just quietly strip them out (and
throw a warning). Others think that it should throw an exception and
croak. Tim said:
The driver should always try to be as transparent as possible.
The general principle is "don't mes with the users data unless
they've specifically asked you to (cf. ChopBlanks)".
Since, however, nulls aren't really allowed in any PostgreSQL data type
(except bytea, and then only if specifically bound as such to a
prepared statement), I'm not sure what to do about this. We can't leave
the data alone unless we just want PostgreSQL to throw an error (likely
to be a mysterious error, as the user won't know why her data is
getting truncated).
I think...throw an exception, since PostgreSQL can't handle the null
byte. Then it will be up to the user to clean up her data, and we won't
have to touch it.
Thoughts?
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 02:35 Bruce Momjian <pgman@candle.pha.pa.us>
parent: David Wheeler <david@wheeler.net>
0 siblings, 0 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-15 02:35 UTC (permalink / raw)
To: David Wheeler <david@wheeler.net>; +Cc: Ian Barwick <barwick@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org
David Wheeler wrote:
> Since, however, nulls aren't really allowed in any PostgreSQL data type
> (except bytea, and then only if specifically bound as such to a
> prepared statement), I'm not sure what to do about this. We can't leave
> the data alone unless we just want PostgreSQL to throw an error (likely
> to be a mysterious error, as the user won't know why her data is
> getting truncated).
>
> I think...throw an exception, since PostgreSQL can't handle the null
> byte. Then it will be up to the user to clean up her data, and we won't
> have to touch it.
Yep, throw an error, and maybe point to bytea as the solution, until we
have a better one. ;-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-15 23:36 Ian Barwick <barwick@gmx.net>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Ian Barwick @ 2002-12-15 23:36 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
On Sunday 15 December 2002 02:09, Bruce Momjian wrote:
>
> Until we release it, the patch can just sit in CVS. Just send over a
> new version and I will back out the old one and put in the new one. I
> will not do any release until you are ready.
Having looked it again I think it can stay as it is.
(It is not very elegant but will fix things until something
better comes along).
Attached is a supplemental patch with an addition for
the POD documentation in Pg.pm regarding the status
of schema support in DBD::Pg.
Ian Barwick
barwick@gmx.net
Attachments:
[text/x-diff] Pg.pm.patch (3.4K, ../../200212160036.26713.barwick@gmx.net/2-Pg.pm.patch)
download | inline diff:
Index: dbdpg/Pg.pm
===================================================================
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/Pg.pm,v
retrieving revision 1.16
diff -c -r1.16 Pg.pm
*** dbdpg/Pg.pm 14 Dec 2002 23:35:47 -0000 1.16
--- dbdpg/Pg.pm 15 Dec 2002 23:28:50 -0000
***************
*** 1506,1512 ****
=head2 Large Objects
The driver supports all large-objects related functions provided by libpq via
! the func-interface. Please note, that starting with PoostgreSQL-65. any access
to a large object - even read-only - has to be put into a transaction!
=head2 Cursors
--- 1506,1512 ----
=head2 Large Objects
The driver supports all large-objects related functions provided by libpq via
! the func-interface. Please note, that starting with PostgreSQL 6.5 any access
to a large object - even read-only - has to be put into a transaction!
=head2 Cursors
***************
*** 1522,1537 ****
=head2 Data-Type bool
The current implementation of PostgreSQL returns 't' for true and 'f' for
! false. From the perl point of view a rather unfortunate choice. The DBD-Pg
module translates the result for the data-type bool in a perl-ish like manner:
'f' -> '0' and 't' -> '1'. This way the application does not have to check the
! database-specific returned values for the data-type bool, because perl treats
'0' as false and '1' as true.
! PostgreSQL Version 6.2 considers the input 't' as true and anything else as
! false. PostgreSQL Version 6.3 considers the input 't', '1' and 1 as true and
! anything else as false. PostgreSQL Version 6.4 considers the input 't', '1'
! and 'y' as true and any other character as false.
=head1 SEE ALSO
--- 1522,1559 ----
=head2 Data-Type bool
The current implementation of PostgreSQL returns 't' for true and 'f' for
! false. From the Perl point of view a rather unfortunate choice. The DBD::Pg
module translates the result for the data-type bool in a perl-ish like manner:
'f' -> '0' and 't' -> '1'. This way the application does not have to check the
! database-specific returned values for the data-type bool, because Perl treats
'0' as false and '1' as true.
! Boolean values can be passed to PostgreSQL as TRUE, 't', 'true', 'y', 'yes' or
! '1' for true and FALSE, 'f', 'false', 'n', 'no' or '0' for false.
!
! =head2 Schema support
!
! PostgreSQL version 7.3 introduced schema support. Note that the PostgreSQL
! schema concept may differ to that of other databases. Please refer to the
! PostgreSQL documentation for more details.
!
! Currently DBD::Pg does not provide explicit support for PostgreSQL schemas.
! However, schema functionality may be used without any restrictions by
! explicitly addressing schema objects, e.g.
!
! my $res = $dbh->selectall_arrayref("SELECT * FROM my_schema.my_table");
!
! or by manipulating the schema search path with SET search_path, e.g.
!
! $dbh->do("SET search_path TO my_schema, public");
!
! B<NOTE:> If you create an object with the same name as a PostgreSQL system
! object (as contained in the pg_catalog schema) and explicitly set the search
! path so that pg_catalog comes after the new object's schema, some DBD::Pg
! methods (particularly those querying PostgreSQL system objects) may fail.
! This problem should be fixed in a future release of DBD::Pg. Creating objects
! with the same name as system objects (or beginning with 'pg_') is not
! recommended practice and should be avoided in any case.
=head1 SEE ALSO
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-30 04:57 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 0 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-30 04:57 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Ian Barwick <barwick@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
Where are we on the release of a new DBDpg version? As I remember the
only open item is handling binary values, but at this point, maybe we
should just push out a release and fix it later.
---------------------------------------------------------------------------
Bruce Momjian wrote:
>
> Thanks. Patch applied. David, time to package up a new version of DBD:Pg?
>
> ---------------------------------------------------------------------------
>
> Ian Barwick wrote:
> > On Monday 09 December 2002 17:03, Tom Lane wrote:
> > > Ian Barwick <barwick@gmx.net> writes:
> > > > To avoid voodoo with PostgreSQL version numbers
> > > > a check is made whether pg_relcheck exists and
> > > > the appropriate query (either 7.3 or pre 7.3)
> > > > executed.
> > >
> > > I would think that looking at version number (select version())
> > > would be a much cleaner approach. Or do you think that direct
> > > examination of pg_class is a version-independent operation?
> >
> > No, but I was hoping it will remain stable for long enough
> > for what is basically a temporary work around until a revised version of
> > DBD::Pg can be produced. It doesn't make any more assumptions
> > about pg_class than are made elsewhere in the current Pg.pm.
> >
> > > This inquiry into pg_relcheck's existence is already arguably wrong
> > > in 7.3 (since it's not taking account of which schema pg_relcheck
> > > might be found in) and it can only go downhill in future versions.
> >
> > Doh. Knew I had to be missing something obvious. (Of course,
> > anyone using current DBD::Pg with 7.3 as is will have to take
> > extra care with system tables and schema namespaces anyway.)
> >
> > So out with the candle wax and pins ;-). Am I right
> > in thinking that the string returned by SELECT version()
> > starts with the word "PostgreSQL" followed by:
> > a space;
> > a single digit indicating the major version number;
> > a full stop / decimal point;
> > a single digit indicating the minor version number;
> > and either "interim release" number (e.g. ".1" in the case of 7.3.1), or
> > "devel", "rc1" etc. ?
> > And that this has been true since 6.x and will continue for the forseeable
> > future (i.e. far far longer than the intended lifespan of attached patch)?
> >
> >
> > Ian Barwick
> > barwick@gmx.net
> >
> > Attached: revised patch
> >
> >
> >
> >
> >
> >
>
> [ Attachment, skipping... ]
>
> --
> 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 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: Patch for DBD::Pg pg_relcheck problem
@ 2002-12-30 04:59 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Ian Barwick <barwick@gmx.net>
0 siblings, 0 replies; 22+ messages in thread
From: Bruce Momjian @ 2002-12-30 04:59 UTC (permalink / raw)
To: Ian Barwick <barwick@gmx.net>; +Cc: dbi-dev@perl.org; pgsql-interfaces@postgresql.org; david@wheeler.net
Patch applied. Thanks.
---------------------------------------------------------------------------
Ian Barwick wrote:
> On Sunday 15 December 2002 02:09, Bruce Momjian wrote:
> >
> > Until we release it, the patch can just sit in CVS. Just send over a
> > new version and I will back out the old one and put in the new one. I
> > will not do any release until you are ready.
>
> Having looked it again I think it can stay as it is.
> (It is not very elegant but will fix things until something
> better comes along).
>
> Attached is a supplemental patch with an addition for
> the POD documentation in Pg.pm regarding the status
> of schema support in DBD::Pg.
>
>
> Ian Barwick
> barwick@gmx.net
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 22+ messages in thread
end of thread, other threads:[~2002-12-30 04:59 UTC | newest]
Thread overview: 22+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2002-12-09 15:31 Patch for DBD::Pg pg_relcheck problem Ian Barwick <barwick@gmx.net>
2002-12-09 16:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2002-12-09 23:34 ` Ian Barwick <barwick@gmx.net>
2002-12-09 23:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2002-12-10 15:38 ` Ian Barwick <barwick@gmx.net>
2002-12-10 15:48 ` Tom Lane <tgl@sss.pgh.pa.us>
2002-12-11 03:50 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-11 19:44 ` Greg Copeland <greg@CopelandConsulting.Net>
2002-12-12 00:19 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-10 15:54 ` Lee Kindness <lkindness@csl.co.uk>
2002-12-10 16:35 ` Ian Barwick <barwick@gmx.net>
2002-12-11 03:49 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-14 23:37 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-14 23:53 ` Ian Barwick <barwick@gmx.net>
2002-12-15 01:09 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-15 23:36 ` Ian Barwick <barwick@gmx.net>
2002-12-30 04:59 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-15 01:36 ` David Wheeler <david@wheeler.net>
2002-12-15 01:46 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-15 01:58 ` David Wheeler <david@wheeler.net>
2002-12-15 02:35 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-12-30 04:57 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox