>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:

 >> - this still has everything in amapi.c rather than creating any new
 >> files. Also, the regression tests are in create_index.sql for lack
 >> of any obviously better place.

 Tom> This more than doubles the size of amapi.c, so it has a definite
 Tom> feel of tail-wags-dog for me, even if that seemed like an
 Tom> appropriate place otherwise which it doesn't really.  I think a
 Tom> new .c file under adt/ is the way to go, with extern declarations
 Tom> in builtins.h.

Yeah, I'm fine with that.  adt/amutils.c unless I see some better

 Tom> Maybe we need a new regression test case file too.  I don't much
 Tom> like adding this to create_index because (a) it doesn't
 Tom> particularly seem to match that file's purpose of setting up
 Tom> indexes on the standard regression test tables, and (b) that file
 Tom> is a bottleneck in parallel regression runs because it can't run
 Tom> in parallel with much else.

Good point. I looked around to see if anything was testing
pg_get_indexdef, thinking that that would be a good place, but it seems
that pg_get_indexdef is tested only in incidental ways (in collate and
rules, the latter of which tests it only with invalid input).

I'll do the next version with a new file, unless a better idea shows up.

 >> Comments?

 Tom> Why did you go with "capability" rather than "property" in the
 Tom> exposed function names?  The latter seems much closer to le mot
 Tom> juste, especially for things like asc/desc.

The first version (which dealt only with AMs) went with "capability"
because it was dealing with what the AM _could_ do rather than what was
defined on any specific index.

The second version added pg_index_column_has_property because that was
the name that had been used in discussion.

Changing them all to "property" would be more consistent I suppose.

 Tom> I'd personally cut the list of pg_am replacement properties way
 Tom> back, as I believe much of what you've got there is not actually
 Tom> of use to applications, and some of it is outright
 Tom> counterproductive.  An example is exposing amcanreturn as an
 Tom> index-AM boolean.

For AM-wide properties, it may be that they have to be considered
"lossy" when tested against the AM oid rather than on an individual
index or column - at the AM level, "false" might mean "this won't work"
while "true" would mean "this might work sometimes, not guaranteed to
work on every index".  The documentation should probably indicate this.

So these properties (I've changed all the names here, suggestions
welcome for better ones) I think should be testable on the AM, each with
an example of why:

    - if this is false, an admin tool shouldn't try and put ASC or DESC
      in a CREATE INDEX

    - if this is false, an admin tool might, for example, want to not
      offer the user the option of CREATE UNIQUE INDEX with this AM

    - if this is false, an admin tool might want to allow the user to
      select only one column

    - a new property that indicates whether the AM can be used for
      exclusion constraints; at present this matches "amgettuple" but
      that implementation detail should of course be hidden

(One possible refinement here could be to invert the sense of all of
these, making them no_whatever, so that "false" and "null" could be
treated the same by clients. Or would that be too confusing?)

These could be limited to being testable only on a specified index, and
not AM-wide:

  optional_key (? maybe)
  predicate_locks (? maybe)

And these for individual columns:

  search_array  (? maybe)
  search_nulls  (? maybe)
  operator_orderable  (or distance_orderable? what's a good name?)

A question: implementing can_return as a per-column property looks like
it requires actually opening the index rel, rather than just consulting
the syscache the way that most pg_get_* functions do. Should it always
open it, or only for properties that need it?

Andrew (irc:RhodiumToad)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to