Skip Menu |

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 88439
Status: rejected
Priority: 0/
Queue: DBD-Pg

People
Owner: greg [...] turnstep.com
Requestors: joost [...] quarantainenet.nl
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Incompatibility between postgres 9.2 and DBD:Pg (table_info and primary_key_info)
Date: Thu, 05 Sep 2013 16:02:39 +0200
To: bug-DBD-Pg [...] rt.cpan.org
From: Casper Joost Eyckelhof <joost [...] quarantainenet.nl>
Summary: DBD::Pg generates queries that reference a no longer existing field (in postgres 9.2) Seen on DBD::Pg versions packaged with Debian Squeeze and Debian Wheezy, but "incompatible code" is still there in latest DBD:Pg (DBD-Pg-2.19.3). Error: DBD::Pg::db table_info failed: ERROR: column t.spclocation does not exist LINE 11: ...t(t.spcname) AS "pg_tablespace_name", quote_ident(t.spclocat... Changelog from postgres 9.2 states: ( http://www.postgresql.org/docs/9.2/interactive/release-9-2.html ) "E.5.2.1. System Catalogs Remove the spclocation field from pg_tablespace (Magnus Hagander) This field was duplicative of the symbolic links that actually define tablespace locations, and thus risked errors of omission when moving a tablespace. This change allows tablespace directories to be moved while the server is down, by manually adjusting the symbolic links. To replace this field, we have added pg_tablespace_location() to allow querying of the symbolic links." Quick fix for postgres 9.2 is replacing "quote_ident(t.spclocation)" by "quote_ident(pg_tablespace_location(t.oid))" at least twice in DBD::Pg, in the functions table_info and primary_key_info. But this will probably break things for postgres <= 9.1. -- Regards, Casper Joost Eyckelhof Quarantainenet BV The Netherlands
That is unusual - can you doublecheck the version? DBD::Pg 2.19.3 definitely has solved this problem. See ticket 77042. It could be some other strange interaction such as a failure to detect the correct Postgres backend version number and thus generating the wrong SQL. Does your Pg.pm contain these lines?: if ($dbh->{private_dbdpg}{version} >= 90200) { $pri_key_sql =~ s/t.spclocation/pg_tablespace_location(t.oid)/; }
Subject: Re: [rt.cpan.org #88439] Incompatibility between postgres 9.2 and DBD:Pg (table_info and primary_key_info)
Date: Fri, 06 Sep 2013 08:35:40 +0200
To: bug-DBD-Pg [...] rt.cpan.org
From: Casper Joost Eyckelhof <joost [...] quarantainenet.nl>
Hi, I just downloaded the newest sources from CPAN again, and the special case for ">= 90200" is there. I assume that it was there the first time too and I somehow missed it, or downloaded another version by mistake :) The fix does seem to be missing in Debian Wheezy though (2.19.2-2), but that is something I have to report to the Debian team. Thanks for the quick response and sorry for the misleading report. On 5-9-2013 16:36, Greg Sabino Mullane via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=88439 > > > That is unusual - can you doublecheck the version? DBD::Pg 2.19.3 definitely has solved this problem. See ticket 77042. It could be some other strange interaction such as a failure to detect the correct Postgres backend version number and thus generating the wrong SQL. Does your Pg.pm contain these lines?: > > if ($dbh->{private_dbdpg}{version} >= 90200) { > $pri_key_sql =~ s/t.spclocation/pg_tablespace_location(t.oid)/; > }
-- Met vriendelijke groet, Casper Joost Eyckelhof Quarantainenet BV
Show quoted text
> Thanks for the quick response and sorry for the misleading report.
Thank you for taking the time to report it. We strive to keep upstream and downstram in sync as much as possible, so please keep us posted about any Debian findings.