|
Home > Archive > PostgreSQL JDBC > April 2005 > _pg_keyposition is gone in HEAD
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
_pg_keyposition is gone in HEAD
|
|
| Dave Cramer 2005-04-27, 3:24 am |
| 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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
| |
| Tom Lane 2005-04-27, 3:24 am |
| Dave Cramer <pg@fastcrypt.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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
| |
| Dave Cramer 2005-04-27, 7:24 am |
| 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@fastcrypt.com> writes:
>
>
>
>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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
| |
| Tom Lane 2005-04-27, 9:23 am |
| 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere
" to majordomo@postgresql
.org)
| |
| Kris Jurka 2005-04-28, 3:24 am |
|
On Wed, 27 Apr 2005, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
>
> 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Kris Jurka 2005-04-28, 11:24 am |
|
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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
|
|
|
|
|