Thread: System catalog future changes

System catalog future changes

From
Steve Midgley
Date:
Hello again,

Reading a previous recent post and answers called "Describe Table" got 
me thinking about a little piece of SQL I use in an application to get 
a list of all the tables for a specific namespace:

select pg_class.relname as table_name
from pg_class join pg_namespace on pg_namespace.oid = relnamespace
where pg_class.relkind = 'r' and pg_namespace.nspname = 'public'
order by pg_class.relname

I have assumed that this sort of query would be relatively "durable" - 
that future system catalog changes are unlikely to make this query stop 
working? Does anyone have any knowledge of how "fixed" the columns and 
values of this query are (i.e. are there a lot of internal and external 
dependencies that make future Pg versiosn unlikely to break the above 
code)?

Any other input on the above SQL - should I be doing this in another 
way?

Thanks for any thoughts or advice,

Steve



Re: System catalog future changes

From
"Pavel Stehule"
Date:
Hello

use information schema instead:  SELECT * FROM information_schema.tables;  SELECT * FROM information_schema.columns ;

Structure of these tables is specified in ANSI SQL. But nobody can be
sure so all these table are stable forever. System catalog isn't fixed
and can be changed every mayor release.  Or better, use own wrapper
views:

CREATE myTables AS SELECT * FROM pg_tables
CREATE myColumns AS SELECT * FROM pg_....

you can fix all future changes only with change these views. and views
have not any overhead in PostgreSQL.

Regards
Pavel Stehule

On 18/12/2007, Steve Midgley <public@misuse.org> wrote:
> Hello again,
>
> Reading a previous recent post and answers called "Describe Table" got
> me thinking about a little piece of SQL I use in an application to get
> a list of all the tables for a specific namespace:
>
> select pg_class.relname as table_name
> from pg_class
>   join pg_namespace on pg_namespace.oid = relnamespace
> where pg_class.relkind = 'r' and pg_namespace.nspname = 'public'
> order by pg_class.relname
>
> I have assumed that this sort of query would be relatively "durable" -
> that future system catalog changes are unlikely to make this query stop
> working? Does anyone have any knowledge of how "fixed" the columns and
> values of this query are (i.e. are there a lot of internal and external
> dependencies that make future Pg versiosn unlikely to break the above
> code)?
>
> Any other input on the above SQL - should I be doing this in another
> way?
>
> Thanks for any thoughts or advice,
>
> Steve
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>


Re: System catalog future changes

From
Erik Jones
Date:
On Dec 18, 2007, at 10:53 AM, Steve Midgley wrote:

> Hello again,
>
> Reading a previous recent post and answers called "Describe Table"
> got me thinking about a little piece of SQL I use in an application
> to get a list of all the tables for a specific namespace:
>
> select pg_class.relname as table_name
> from pg_class
>  join pg_namespace on pg_namespace.oid = relnamespace
> where pg_class.relkind = 'r' and pg_namespace.nspname = 'public'
> order by pg_class.relname
>
> I have assumed that this sort of query would be relatively
> "durable" - that future system catalog changes are unlikely to make
> this query stop working? Does anyone have any knowledge of how
> "fixed" the columns and values of this query are (i.e. are there a
> lot of internal and external dependencies that make future Pg
> versiosn unlikely to break the above code)?
>
> Any other input on the above SQL - should I be doing this in
> another way?
>
> Thanks for any thoughts or advice,

If all you're looking for is regular tables, the I'd use the
pg_tables view.

Erik Jones

Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




Re: System catalog future changes

From
Steve Midgley
Date:
Thanks Erik - that cleans things up significantly for me.

For the record, the SQL for finding all the table
names (alpha ordered) in the public schema using pg_tables view is:

select tablename from pg_tables where
schemaname='public' order by tablename

Steve

At 09:38 AM 12/18/2007, Erik Jones wrote:
>On Dec 18, 2007, at 10:53 AM, Steve Midgley wrote:
>
>>Hello again,
>>
>>Reading a previous recent post and answers called "Describe Table"
>>got me thinking about a little piece of SQL I use in an application
>>to get a list of all the tables for a specific namespace:
>>
>>select pg_class.relname as table_name
>>from pg_class
>>  join pg_namespace on pg_namespace.oid = relnamespace
>>where pg_class.relkind = 'r' and pg_namespace.nspname = 'public'
>>order by pg_class.relname
>>
>>I have assumed that this sort of query would be relatively
>>"durable" - that future system catalog changes are unlikely to make
>>this query stop working? Does anyone have any knowledge of how
>>"fixed" the columns and values of this query are (i.e. are there a
>>lot of internal and external dependencies that make future Pg
>>versiosn unlikely to break the above code)?
>>
>>Any other input on the above SQL - should I be doing this in
>>another way?
>>
>>Thanks for any thoughts or advice,
>
>If all you're looking for is regular tables, the I'd use the
>pg_tables view.
>
>Erik Jones
>
>Software Developer | Emma®
>erik@myemma.com
>800.595.4401 or 615.292.5888
>615.292.0777 (fax)
>
>Emma helps organizations everywhere communicate & market in style.
>Visit us online at http://www.myemma.com
>
>
>