>>>>> "Alvaro" == Alvaro Herrera <alvhe...@2ndquadrant.com> writes:

 >> One idea is utils/adt/misc.c.  Or we could make a new file under
 >> utils/adt/ though I'm not very sure what to name it.  amaccess.c?
 >> catutils.c?  If there's only ever likely to be one or two functions
 >> of this ilk, maybe a new file is overkill and we should just use
 >> misc.c.

 Alvaro> I like the idea of a new file; I have a hunch that it will
 Alvaro> grow, given that we're expanding in this area, and perhaps we
 Alvaro> can find some existing stuff to relocate there in the future.
 Alvaro> I don't think a small file is a problem, anyway.

 Alvaro> How about amfuncs.c?  Maybe it can live in catalog/ instead of
 Alvaro> utils/adt?

Well, the existing patch used access/index/amapi.c for the AM capability
functions. There may be some merit in keeping everything together - I
asked because it didn't seem at first glance that the index column
property function belonged there, but on second thought there's some
overlap in that in future, if indoptions ever acquires any AM-specific
flags, it may be necessary for pg_index_column_has_property to call into
an AM-specific function.

So, here are some options:

1. Put everything in access/index/amapi.c

2. Move either all of access/index/amapi.c, or just the SQL-callable
   part of it (amvalidate), to utils/adt/amfuncs.c and put new stuff in

3. put pg_index[am]_has_capability in access/index/amapi.c and
   pg_index_column_has_property in utils/adt/misc.c

Andrew (irc:RhodiumToad)

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

Reply via email to