Re: No longer possible to query catalogs for index capabilities?
От | Andrew Gierth |
---|---|
Тема | Re: No longer possible to query catalogs for index capabilities? |
Дата | |
Msg-id | 87shu9mtan.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: No longer possible to query catalogs for index capabilities? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> But we need to be clear in the documentation about what thisTom> property actually means. My objection to having itanswer at theTom> index or column level is basically that that encourages confusionTom> as to what it means. OK. Here's new output with the scope changes, and some of the names changed in an attempt to make them clearer: cap | AM | Index | Column --------------------+----+-------+--------asc | | | tdesc | | | fnulls_first | | | fnulls_last | | | torderable | | | tdistance_orderable| | | freturnable | | | tsearch_array | | | tsearch_nulls | | | tclusterable | | t | backward_scan | | t | index_scan | | t |bitmap_scan | | t | can_order | t | | can_unique | t | | can_multi_col | t | | can_exclude | t | | (17 rows) (The can_* names are reserved for the AM level where we're asking about the abstract capabilities of the AM.) Better? Worse? Any more improvements to the names? -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: