Re: _pg_keyposition is gone in HEAD

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pg(at)fastcrypt(dot)com
Cc: List <pgsql-jdbc(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: _pg_keyposition is gone in HEAD
Date: 2005-04-27 14:05:50
Message-ID: 21701.1114610750@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> I is being used to get the position of a key in the database meta data
> getImportedExported keys, to be specific.

That's not clear enough ... what's it being used for exactly?

> My impression was that the information_schema was being provided in
> order to provide an abstraction of the
> internal catalogs, ostensibly to minimize changes to clients when the
> underlying catalogs change from version to version?

The information schema exists to export the SQL-mandated views. There
are one or two auxiliary functions in it that are *NOT* considered part
of the API. If you depend on those then it's at your own risk.

(Arguably, Peter should have put the auxiliary functions in pg_catalog
not in information_schema. This wouldn't really change anything though
as to whether it's safe for clients to depend on them.)

> If this is the case removing it doesn't seem like an option? Shouldn't
> it be re-written to reflect reality below it ?

Not removing it is not an option. It was defined and used in a way that
assumed that func_max_args == index_max_keys, which isn't true any more.
If we left it in place and made it generate keys up to one of those
numbers, we'd silently break clients that used it for the other purpose.
That's not an improvement over removing it.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2005-04-27 14:36:58 Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution
Previous Message Anders Hermansen 2005-04-27 14:05:34 Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution