Re: No longer possible to query catalogs for index capabilities?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: No longer possible to query catalogs for index capabilities?
Дата
Msg-id 5265.1469584987@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: No longer possible to query catalogs for index capabilities?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: No longer possible to query catalogs for index capabilities?  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 7/25/16 3:26 PM, Andrew Gierth wrote:
>> The issue I ran into was the exact same one as in the JDBC thread I
>> linked to earlier: correctly interpreting pg_index.indoption (to get the
>> ASC / DESC and NULLS FIRST/LAST settings), which requires knowing
>> whether amcanorder is true to determine whether to look at the bits at
>> all.

> Maybe we should provide a facility to decode those bits then?

Yeah.  I'm not very impressed by the underlying assumption that it's
okay for client-side code to hard-wire knowledge about what indoption
bits mean, but not okay for it to hard-wire knowledge about which index
AMs use which indoption bits.  There's something fundamentally wrong
in that.  We don't let psql or pg_dump look directly at indoption, so
why would we think that third-party client-side code should do so?

Andrew complained upthread that pg_get_indexdef() was too heavyweight
for his purposes, but it's not clear to me what he wants instead.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: MSVC pl-perl error message is not verbose enough
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH v12] GSSAPI encryption support