On Thursday, December 5, 2002, at 09:44 AM, Jeff Boes wrote:
So what's the answer? At present, we cannot upgrade to PostgreSQL 7.3
because the DBD code will quit working. I could produce a patch that
solves our problem, but I have no facilities or expertise to verify
that
it will work for eve
On Thu, 2002-12-05 at 12:39, David Wheeler wrote:
> I chatted with Bruce Momjian about this a bit, too. My idea: PostgreSQL
> should provide functions that do this sort of thing, so that psql,
> DBD::Pg, org.postgresql.jdbc, and PostgreSQL ODBC can just use the
> functions without worrying about
On Wednesday, December 4, 2002, at 11:40 AM, Jeff Boes wrote:
I received the following communication from Tom Lane, who is active in
PostgreSQL development:
... without so much as a "ta-ta" in the release notes. Hmph. Well,
is
there any hope that a search-and-replace will convert old source
I received the following communication from Tom Lane, who is active in
PostgreSQL development:
> ... without so much as a "ta-ta" in the release notes. Hmph. Well, is
> there any hope that a search-and-replace will convert old source code to
> using the new table?
It shouldn't be a difficult ch
On Wed, Dec 04, 2002 at 08:20:52AM +1100, Steve Baldwin wrote:
> I'm sure this has been asked many times before, but Tim's reply here
> prompted me to ask again. Is there any way to access the DB version (as
> per your example of get_info(18) below) from DBI. For example as an
> attribute of the
On Tue, 2002-12-03 at 16:20, Steve Baldwin wrote:
> I'm sure this has been asked many times before, but Tim's reply here
> prompted me to ask again. Is there any way to access the DB version (as
> per your example of get_info(18) below) from DBI. For example as an
> attribute of the database hand
L PROTECTED]; [EMAIL PROTECTED]
Subject: Re: DBD::Pg 1.20 uncompatible with Postgres 7.3?
On Tue, Dec 03, 2002 at 10:56:47AM -0800, David Wheeler wrote:
> On Tuesday, December 3, 2002, at 10:34 AM, Jeff Boes wrote:
>
> >Nope, not quite:
> >
> >$ grep pg_ Pg.pm
> >
On Tue, Dec 03, 2002 at 10:56:47AM -0800, David Wheeler wrote:
> On Tuesday, December 3, 2002, at 10:34 AM, Jeff Boes wrote:
>
> >Nope, not quite:
> >
> >$ grep pg_ Pg.pm
> >
> >of Pg.pm 1.13 will show you that it relies on pg_database, pg_user,
> >pg_class, pg_description, pg_attribute, pg_type,
On Tuesday 03 December 2002 19:34, Jeff Boes wrote:
> On Tue, 2002-12-03 at 12:16, Ian Barwick wrote:
> > AFAICT DBD::Pg versions prior to 1.20 don't query any pg_ tables
> > and _seem_ not to break anywhere when talking to 7.3 . I think
> > $dbh->table_attributes() etc. were added in 1
On Tuesday, December 3, 2002, at 10:34 AM, Jeff Boes wrote:
Nope, not quite:
$ grep pg_ Pg.pm
of Pg.pm 1.13 will show you that it relies on pg_database, pg_user,
pg_class, pg_description, pg_attribute, pg_type, pg_index, pg_attrdef,
and pg_relcheck. All but the last one are still in 7.3.
tabl
On Tue, 2002-12-03 at 12:16, Ian Barwick wrote:
> AFAICT DBD::Pg versions prior to 1.20 don't query any pg_ tables
> and _seem_ not to break anywhere when talking to 7.3 . I think
> $dbh->table_attributes() etc. were added in 1.20.
>
> You may have more luck with DBD::PG 1.13 for the moment.
>
On Tuesday 03 December 2002 17:32, Jeff Boes wrote:
> On Tue, 2002-12-03 at 11:12, Jeff Boes wrote:
> > We may have uncovered an incompatibility with DBD::Pg (version 1.20 is
> > the latest we have) and the newly-released PostgreSQL 7.3.
> >
> > It appears that the DESTROY method for database and/o
On Tuesday, December 3, 2002, at 08:32 AM, Jeff Boes wrote:
Oops. The problem is still there, but I've narrowed it down; it's not
in the DESTROY method at all, but in $dbh->table_attributes:
Use of uninitialized value in split at
/usr/lib/perl5/site_perl/5.6.1/i686-linux/DBD/Pg.pm line 576.
E
On Tue, 2002-12-03 at 11:12, Jeff Boes wrote:
> We may have uncovered an incompatibility with DBD::Pg (version 1.20 is
> the latest we have) and the newly-released PostgreSQL 7.3.
>
> It appears that the DESTROY method for database and/or statement handles
> is referencing a system table ("pg_relc
We may have uncovered an incompatibility with DBD::Pg (version 1.20 is
the latest we have) and the newly-released PostgreSQL 7.3.
It appears that the DESTROY method for database and/or statement handles
is referencing a system table ("pg_relcheck") that no longer exists.
Attached is the trace tha
15 matches
Mail list logo
