Re: _pg_keyposition is gone in HEAD - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: _pg_keyposition is gone in HEAD
Date
Msg-id 21701.1114610750@sss.pgh.pa.us
Whole thread Raw
In response to Re: _pg_keyposition is gone in HEAD  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: _pg_keyposition is gone in HEAD
List pgsql-jdbc
Dave Cramer <pg@fastcrypt.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

pgsql-jdbc by date:

Previous
From: Anders Hermansen
Date:
Subject: Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution
Next
From: Tom Lane
Date:
Subject: Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution