Обсуждение: psql: no schema info

have several schemae, each with identical tables.

in create scripts have been taking great care to fully qualify, eg, col1 references schema1.tab1( col1 )

however, just got burnt big time on sequences!  need to qualify them as
well, eg col1 integer default nextval( 'schema1.seq1' )

\dt is no help at all since it does not specify schema so it's
impossible to know if all is aligned correctly.  is there a way to tell
psql to fully qualify relations in the listing?

when everything was in public this wasn't a problem, but with elaborate
use of schemae it's pretty scary (for me).

     ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

chester c young <chestercyoung@yahoo.com> writes:
> however, just got burnt big time on sequences!  need to qualify them as
> well, eg
>   col1 integer default nextval( 'schema1.seq1' )

Move to something newer than 8.0.x, and this is automatic (because
nextval's argument is actually a regclass constant).
        regards, tom lane

> > however, just got burnt big time on sequences!  need to qualify
> them as
> > well, eg
> >   col1 integer default nextval( 'schema1.seq1' )
> 
> Move to something newer than 8.0.x, and this is automatic (because
> nextval's argument is actually a regclass constant).
> 
>             regards, tom lane

using 8.2 and 8.3

here's (psychological) problem as I see it:

# set search_path=old_schema;
#
# create sequence new_schema.seq1;
#
# create table new_schema.table1(
#    col1 integer default nextval( 'seq1' )
# );

using old_schema.seq1, not new_schema.seq1

and imho to make matters more difficult to troubleshoot:

# \dt table1 -> does not show which schema for seq1


     ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

chester c young wrote:
> using 8.2 and 8.3
> 
> here's (psychological) problem as I see it:
> 
> # set search_path=old_schema;
> #
> # create sequence new_schema.seq1;
> #
> # create table new_schema.table1(
> #    col1 integer default nextval( 'seq1' )
> # );
> 
> using old_schema.seq1, not new_schema.seq1
> 
> and imho to make matters more difficult to troubleshoot:
> 
> # \dt table1 -> does not show which schema for seq1

Must admit I thought you were wrong, but having tested it, I think I see 
what you mean.

If the schema in question is in the search_path then it doesn't get 
displayed. If you've forgotten what your search_path is set to then that 
can cause confusion.

Not a problem I see much of since I very rarely change my search_path. I  refer to schema.table by preference.

--   Richard Huxton  Archonet Ltd

chester c young wrote:

> # create table new_schema.table1(
> #    col1 integer default nextval( 'seq1' )
> # );
> 
> using old_schema.seq1, not new_schema.seq1

Yes, that's correct -- assuming you had an old_schema.seq1 sequence too.

> and imho to make matters more difficult to troubleshoot:
> 
> # \dt table1 -> does not show which schema for seq1

I agree it can be confusing if you're not looking for it.

alvherre=# set search_path to old_s;
SET
alvherre=# \d new_s.table1                Tabla «new_s.table1»Columna |  Tipo   |           Modificadores           
---------+---------+-----------------------------------col1    | integer | default nextval('seq1'::regclass)

Here, the nextval() is correctly _not_ qualified, because the current
search path is the sequence's schema.  But it is certainly confusing.

You have to set the search_path to the table's search path for the
problem to be obvious:

alvherre=# set search_path to new_s;
SET
alvherre=# \d new_s.table1                   Tabla «new_s.table1»Columna |  Tipo   |              Modificadores
    
 
---------+---------+-----------------------------------------col1    | integer | default
nextval('old_s.seq1'::regclass)

alvherre=# \d table1                   Tabla «new_s.table1»Columna |  Tipo   |              Modificadores

---------+---------+-----------------------------------------col1    | integer | default
nextval('old_s.seq1'::regclass)


I'm not sure what's a good solution here.  Perhaps the \d command should
temporarily set the schema to something that would cause regclass to
display qualified names all the time, when you passed it a qualified
name (using SET LOCAL perhaps, but reverting to the original value after
then \d is done).  You can't just use a nonexistant schema or some kind
of NULL or empty value, because SET rejects it.  I can set it to $user,
which is accepted but doesn't exist on my scratch database:

alvherre=# set search_path to '$user';
SET
alvherre=# \d new_s.table1                   Tabla «new_s.table1»Columna |  Tipo   |              Modificadores
    
 
---------+---------+-----------------------------------------col1    | integer | default
nextval('old_s.seq1'::regclass)


Another option would be to set it to the given schema, so that any name
not on that schema is qualified.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> > # \dt table1 -> does not show which schema info.

was wrong on this - \dt shows schema for relations _not_ in the search
path.

my new good practice is to keep search_path = PUBLIC so all schema info
is displayed always all the time invariably.


     ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ