Robert Haas <robertmh...@gmail.com> writes: > On Jan 16, 2016, at 11:13 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> There are a couple of things we could do instead: >> >> * Put each amvalidate function into its own file (but probably keep it >> in the same directory as now). This is a reasonable response to >> points #1 and #2 but isn't very much help for #3. >> >> * Collect the amvalidate functions into one file, which then leaves >> us wondering where to put that; surely not under any one AM's directory. >> A new file in src/backend/access/index/ is one plausible solution. >> This file would also be a reasonable place to put the amvalidate() >> dispatch function itself. >> >> I'm somewhat leaning to the second choice, but perhaps someone has >> a better idea, or an argument against doing that.
> Doesn't seem very modular. How about putting common code there but > AM-specific code in each AM's directory? It would be nice if adding a new AM > meant mostly adding a new directory, not much touching the common code. Then we're going to end up with option A; and I suspect that we'll never bother with factoring out any common code, because it won't be worth the notational trouble if it involves common code that's in a different file in a different directory. As for modularity, nobody's moaned particularly about the amcostestimate functions all being in selfuncs.c. It all depends on what you think is "modular". regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers