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?
|
Список | 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 по дате отправления: