Re: _pg_keyposition is gone in HEAD

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: _pg_keyposition is gone in HEAD
Date: 2005-04-27 11:51:04
Message-ID: 426F7CA8.1010200@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Anders Hermansen 2005-04-27 11:54:34 Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution
Previous Message Anders Hermansen 2005-04-27 10:50:49 Re: ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1 possiblesolution