Re: _pg_keyposition is gone in HEAD

This function is being used in getImportedExported keys.

Does anyone know how to work around this ?

--dc--

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> This function is being used in getImportedExported keys.

To do what exactly?

I got rid of it in CVS tip because it was wired into the assumption
that INDEX_MAX_KEYS = FUNC_MAX_ARGS, which is not simply not true
anymore: the latter constant doesn't even exist anymore. So you've
got to explain what you were using it for before we can talk about
solutions.

regards, tom lane

I is being used to get the position of a key in the database meta data
getImportedExported keys, to be specific.

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

Dave

Tom Lane wrote:

>Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>
>
>>This function is being used in getImportedExported keys.
>>
>>
>
>To do what exactly?
>
>I got rid of it in CVS tip because it was wired into the assumption
>that INDEX_MAX_KEYS = FUNC_MAX_ARGS, which is not simply not true
>anymore: the latter constant doesn't even exist anymore. So you've
>got to explain what you were using it for before we can talk about
>solutions.
>
> regards, tom lane
>
>
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

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

On Wed, 27 Apr 2005, Tom Lane wrote:

> 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?

Basically _pg_keyposition just generates a resultset of sequential
integers, we could use generate_series now using the value of
max_index_keys to determine the upper bound. So it seems like
the jdbc driver will be ok, do other apps need a new display only
GUC for max_func_args ?

Kris Jurka

On Wed, 27 Apr 2005, Dave Cramer wrote:

> This function is being used in getImportedExported keys.
>
> Does anyone know how to work around this ?
>

I've committed a fix to cvs for this.

Kris Jurka