Skip Menu |

This queue is for tickets about the SQL-Translator CPAN distribution.

Report information
The Basics
Id: 61757
Status: resolved
Priority: 0/
Queue: SQL-Translator

People
Owner: Nobody in particular
Requestors: tim.esselens [...] gmail.com
Cc:
AdminCc:

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



Subject: PATCH: PostgreSQL: query all non-system db_schemas for tables (key: search_path)
Date: Wed, 29 Sep 2010 16:19:00 +0200
To: bug-SQL-Translator [...] rt.cpan.org
From: Tim Esselens <tim.esselens [...] gmail.com>
disambiguation: It's possible to have different db_schemas in PostgreSQL which can be set with search_path. It has nothing to do with the schema definition of a table. It's just another level of separation inside the db. This patch will query all non system schemas for tables. WARNING: since a tablename might not be unique unless fully qualified (ie: with the schema prepended), this patch prepends the schema_name. Therefore it might mess up conversions to other SQL dialects. YMMV. The purpose of this patch is to be able to draw diagrams with tables from different database schemas Patch is only tested using sqlt -f DBI-PostgreSQL -t {HTML, Diagram} Index: lib/SQL/Translator/Parser/DBI/PostgreSQL.pm =================================================================== --- lib/SQL/Translator/Parser/DBI/PostgreSQL.pm (revision 1703) +++ lib/SQL/Translator/Parser/DBI/PostgreSQL.pm (working copy) @@ -73,9 +73,9 @@ ); my $table_select = $dbh->prepare( - "SELECT oid,relname FROM pg_class WHERE relnamespace IN - (SELECT oid FROM pg_namespace WHERE nspname='public') - AND relkind='r';" + "SELECT c.oid,(select nspname from pg_namespace n where n.oid = c.relnamespace) || '.' || relname as relname FROM pg_class c WHERE c.relnamespace IN + (SELECT oid FROM pg_namespace WHERE nspname !~ '^pg_' and nspname != 'information_schema') + AND relkind='r'" ); my $fk_select = $dbh->prepare( @@ -112,7 +112,6 @@ ON n.oid = c.relnamespace WHERE pg_catalog.pg_table_is_visible(c.oid) - AND n.nspname = ? AND c.relname = ? ORDER BY 1; /) or die "Can't prepare: $@"; @@ -182,14 +181,15 @@ ) || die $table->error; } - $fk_select->execute('public',$table_name) or die "Can't execute: $@"; + my ($db_schema, $short_table_name) = split /\./o, $table_name; + $fk_select->execute($short_table_name) or die "Can't execute: $@"; my $fkeys = $fk_select->fetchall_arrayref({}); $DEBUG and print Dumper $fkeys; for my $con (@$fkeys){ my $con_name = $con->{conname}; my $fields = $con->{fields}; my $reference_fields = $con->{reference_fields}; - my $reference_table = $con->{frelname}; + my $reference_table = $db_schema . '.' . $con->{frelname}; my $on_upd = $con->{confupdtype}; my $on_del = $con->{confdeltype}; $table->add_constraint(

Message body is not shown because sender requested not to inline it.

On Wed Sep 29 10:19:12 2010, tim.esselens@gmail.com wrote: Show quoted text
> disambiguation: It's possible to have different db_schemas in > PostgreSQL which can be set with search_path. > It has nothing to do with the schema definition of a table. It's just > another level of separation inside the db. > > This patch will query all non system schemas for tables. > > WARNING: since a tablename might not be unique unless fully qualified > (ie: with the schema prepended), this patch prepends the schema_name. > Therefore it might mess up conversions to other SQL dialects. YMMV. > > The purpose of this patch is to be able to draw diagrams with tables > from different database schemas > > Patch is only tested using sqlt -f DBI-PostgreSQL -t {HTML, Diagram} > > Index: lib/SQL/Translator/Parser/DBI/PostgreSQL.pm >
========================================================== ========= Show quoted text
> --- lib/SQL/Translator/Parser/DBI/PostgreSQL.pm (revision 1703) > +++ lib/SQL/Translator/Parser/DBI/PostgreSQL.pm (working copy) > @@ -73,9 +73,9 @@ > ); > > my $table_select = $dbh->prepare( > - "SELECT oid,relname FROM pg_class WHERE relnamespace IN > - (SELECT oid FROM pg_namespace WHERE nspname='public') > - AND relkind='r';" > + "SELECT c.oid,(select nspname from pg_namespace n where n.oid > = c.relnamespace) || '.' || relname as relname FROM pg_class c WHERE > c.relnamespace IN > + (SELECT oid FROM pg_namespace WHERE nspname !~ '^pg_' and > nspname != 'information_schema') > + AND relkind='r'" > ); > > my $fk_select = $dbh->prepare( > @@ -112,7 +112,6 @@ > ON n.oid = c.relnamespace > > WHERE pg_catalog.pg_table_is_visible(c.oid) > - AND n.nspname = ? > AND c.relname = ? > ORDER BY 1; > /) or die "Can't prepare: $@"; > @@ -182,14 +181,15 @@ > ) || die $table->error; > } > > - $fk_select->execute('public',$table_name) or die "Can't > execute: $@"; > + my ($db_schema, $short_table_name) = split /\./o, > $table_name; > + $fk_select->execute($short_table_name) or die "Can't execute: > $@"; > my $fkeys = $fk_select->fetchall_arrayref({}); > $DEBUG and print Dumper $fkeys; > for my $con (@$fkeys){ > my $con_name = $con->{conname}; > my $fields = $con->{fields}; > my $reference_fields = $con->{reference_fields}; > - my $reference_table = $con->{frelname}; > + my $reference_table = $db_schema . '.' . $con-
> >{frelname};
> my $on_upd = $con->{confupdtype}; > my $on_del = $con->{confdeltype}; > $table->add_constraint(
Can you run the full test suite against this patch? My concern is that it might deeply screw with ddl diffs. Additionally, perhaps it would be better to just search for all tables that are found in the search path? as opposed to all non system tables, with schema prefixed. that way you'd have some control over it at connect time. johnn
Subject: Re: [rt.cpan.org #61757] PATCH: PostgreSQL: query all non-system db_schemas for tables (key: search_path)
Date: Thu, 26 Jan 2012 17:36:10 +0100
To: bug-SQL-Translator [...] rt.cpan.org
From: Tim Esselens <tim.esselens [...] gmail.com>
Show quoted text
> Can you run the full test suite against this patch?  My concern is that it might deeply screw with > ddl diffs.  Additionally, perhaps it would be better to just search for all tables that are found in > the search path?  as opposed to all non system tables, with schema prefixed.  that way you'd > have some control over it at connect time.
The patch can no longer be cleanly applied. And from what I see in the sources the queries have changed to take the namespace into account. It's possible however that it is not further developed (as 'public' is hardcoded) because of incompatibilities. If this is functionality you require it's a matter of adding an extra variable, but I don't know that 'foo.bar' is allowed, please let me know if/how I could assist further, maybe revert to an older version to test that? Show quoted text
> johnn
-- kind regards, Tim Esselens
On Thu Jan 26 11:36:17 2012, tim.esselens@gmail.com wrote: Show quoted text
> > Can you run the full test suite against this patch?  My concern is
> that it might deeply screw with
> > ddl diffs.  Additionally, perhaps it would be better to just search
> for all tables that are found in
> > the search path?  as opposed to all non system tables, with schema
> prefixed.  that way you'd
> > have some control over it at connect time.
> > The patch can no longer be cleanly applied. And from what I see in the > sources the queries have changed to take the namespace into account. > > It's possible however that it is not further developed (as 'public' is > hardcoded) because of incompatibilities. > > If this is functionality you require it's a matter of adding an extra > variable, but I don't know that 'foo.bar' is allowed, > > please let me know if/how I could assist further, maybe revert to an > older version to test that? >
Is this still an issue in the version currently in the repository (probably will be on CPAN by the time you read this)? From what I can gather in the backlog it seems that it is already fixed. Is this the case?
Given a lot of stuff to deal with this was added to the Pg parser recently, marking this ticket as resolved. Please feel free to reopen it if the problem still persists.