To: "Dave Page" <dpage@vale-housing.co.uk>
Cc: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>,
	"Hiroshi Inoue" <Inoue@tpf.co.jp>,
	"Bruce Momjian" <pgman@candle.pha.pa.us>,
	pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign 
In-reply-to: <03AF4E498C591348A42FC93DEA9661B8259D8D@mail.vale-housing.co.uk> 
References: <03AF4E498C591348A42FC93DEA9661B8259D8D@mail.vale-housing.co.uk>
Comments: In-reply-to "Dave Page" <dpage@vale-housing.co.uk>
	message dated "Wed, 12 Mar 2003 14:49:15 +0000"
Date: Wed, 12 Mar 2003 10:49:54 -0500
Message-ID: <27130.1047484194@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Dave Page" <dpage@vale-housing.co.uk> writes:
> No, but with them we can avoid cluttering the wire protocol with fields
> for all this, and the JDBC required data. With 2 numeric columns
> (attrelid, attnum), any application/interface can query the system
> catalogs easily for whatever extra info they like.

This is my feeling also.  We shouldn't try to guess in the protocol
exactly what set of information will be wanted by a frontend; we should
just provide the catalog keys needed to look up whatever is wanted.

I like attrelid/attnum because (a) it's compact --- not much added
overhead for apps that don't care; and (b) it's a primary key, which
names are not.  The relid/attnum identity of a column will remain the
same as long as it exists.  A name-based API breaks the moment some
other user renames things; similar objections could be raised against
attlognum, if we had it.

The point about apps breaking if the system catalog layout changes is a
fair one, but that situation would be no worse than it's ever been; ODBC
and JDBC have coped well enough so far.  In any case the best solution
would be to offer functions that hide the details of where to find any
given bit of info.  We've got a few like that already (format_type() for
example) and I have no problem with adding more.

			regards, tom lane