>>>>> "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 there 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: http://www.postgresql.org/mailpref/pgsql-hackers
