Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I think we should make a decision on code arrangement here. From my
> perspective, MERGE isn't its own executor node; rather it's just another
> "method" in ModifyTable. Which makes sense, given that all it does is
> call parts of INSERT, UPDATE, DELETE which are the other ModifyTable
> methods. Having a separate file doesn't strike me as great, but on the
> other hand it's true that merely moving all the execMerge.c code into
> nodeModifyTable.c makes the latter too large. However I don't want to
> create a .h file that means exposing all those internal functions to the
> outside world. My ideal would be to have each INSERT, UPDATE, DELETE,
> MERGE as its own separate .c file, which would be #included from
> nodeModifyTable.c. We don't use that pattern anywhere though. Any
> opposition to that? (The prototypes for each file would have to live in
> nodeModifyTable.c itself.)
Yeah, I don't like that. The point of having separate .c files is that
you know that there's no interactions of non-global symbols across files.
This pattern breaks that assumption, making it harder to see what's
connected to what; and what's it buying exactly? I'd rather keep all the
ModifyTable code in one .c file, even if that one is bigger than our
usual practice.
regards, tom lane