From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Page <dpage@vale-housing.co.uk>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>
Cc: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: Wed, 12 Mar 2003 10:49:54 -0500
Message-ID: <27130.1047484194@sss.pgh.pa.us> (raw)
In-Reply-To: <03AF4E498C591348A42FC93DEA9661B8259D8D@mail.vale-housing.co.uk>
References: <03AF4E498C591348A42FC93DEA9661B8259D8D@mail.vale-housing.co.uk>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, dpage@vale-housing.co.uk, ZeugswetterA@spardat.at, Inoue@tpf.co.jp, pgman@candle.pha.pa.us, pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
In-Reply-To: <27130.1047484194@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox