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