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

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: No longer possible to query catalogs for index capabilities?
Дата
Msg-id 878twadsp6.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: No longer possible to query catalogs for index capabilities?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: No longer possible to query catalogs for index capabilities?  (Bruce Momjian <bruce@momjian.us>)
Re: No longer possible to query catalogs for index capabilities?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
>>>>> "Bruce" == Bruce Momjian <bruce@momjian.us> writes:
>> As far as I understood Andrew's use case, he was specifically *not*>> interested in a complete representation of an
indexdefinition, but>> rather about whether it had certain properties that would be of>> interest to query-constructing
applications.

Well, I wouldn't limit it to query-constructing applications.

I'll give another random example that I thought of. Suppose an
administrative GUI (I have no idea if any of the existing GUIs do this)
has an option to do CLUSTER on a table; how should it know which indexes
to offer the user to cluster on, without access to amclusterable?
Bruce> Would it be helpful to output an array of strings representingBruce> the index definition?

Why would that help, if the point is to enable programmatic access to
information?

Anyway, what I haven't seen in this thread is any implementable
counter-proposal other than the "just hardcode the name 'btree'"
response that was given in the JDBC thread, which I don't consider
acceptable in any sense. Is 9.6 going to go out like this or is action
going to be taken before rc1?

-- 
Andrew (irc:RhodiumToad)



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Quorum commit for multiple synchronous replication.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [sqlsmith] Crash in GetOldestSnapshot()