[SQL] System catalog future changes

2007-12-18 Thread Steve Midgley

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: [SQL] System catalog future changes

2007-12-18 Thread Pavel Stehule
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 [EMAIL PROTECTED] 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


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [SQL] System catalog future changes

2007-12-18 Thread Erik Jones

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®
[EMAIL PROTECTED]
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



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [SQL] System catalog future changes

2007-12-18 Thread Steve Midgley

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®
[EMAIL PROTECTED]
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






---(end of broadcast)---
TIP 6: explain analyze is your friend