DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=uFIugSAfKehH1gPb8wQ2esclp5S8KBfUFTXyC9oSY53r/TjCDRgaltHJZKaXMKsNpGvZY5Eb5o9p5FZViMQsoTfNg5Rrp/T1C8e1x+UUhmqDMei4Ix8Hu0ev47z5+xXvFk2yF3zF5WQrKUuRgqN82yJOf3UOG5HxYjCp/3qJUf8=
Message-ID: <162867790712180936x7792d302pb3ed9f533339ee67@mail.gmail.com>
Date: Tue, 18 Dec 2007 18:36:36 +0100
From: "Pavel Stehule" <pavel.stehule@gmail.com>
To: "Steve Midgley" <public@misuse.org>
Subject: Re: System catalog future changes
Cc: pgsql-sql@postgresql.org
In-Reply-To: <20071218165836.4EFD42E004C@postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20071218165836.4EFD42E004C@postgresql.org>

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
>