In-Reply-To: <20071218165836.4EFD42E004C@postgresql.org>
References: <20071218165836.4EFD42E004C@postgresql.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <2C8AD9F2-4891-4D96-87D1-7101A180CC79@myemma.com>
Cc: pgsql-sql@postgresql.org
Content-Transfer-Encoding: quoted-printable
From: Erik Jones <erik@myemma.com>
Subject: Re: System catalog future changes
Date: Tue, 18 Dec 2007 11:38:00 -0600
To: Steve Midgley <public@misuse.org>

On Dec 18, 2007, at 10:53 AM, Steve Midgley wrote:

> Hello again,
>
> Reading a previous recent post and answers called "Describe Table" =20
> got me thinking about a little piece of SQL I use in an application =20=

> 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 =3D relnamespace
> where pg_class.relkind =3D 'r' and pg_namespace.nspname =3D 'public'
> order by pg_class.relname
>
> I have assumed that this sort of query would be relatively =20
> "durable" - that future system catalog changes are unlikely to make =20=

> this query stop working? Does anyone have any knowledge of how =20
> "fixed" the columns and values of this query are (i.e. are there a =20
> lot of internal and external dependencies that make future Pg =20
> versiosn unlikely to break the above code)?
>
> Any other input on the above SQL - should I be doing this in =20
> another way?
>
> Thanks for any thoughts or advice,

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

Erik Jones

Software Developer | Emma=AE
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