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