From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Department of Redundancy Department: makeNode(FuncCall) division |
Date: | 2013-02-10 15:09:19 |
Message-ID: | 19670.1360508959@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> Per suggestions and lots of help from Andrew Gierth, please find
> attached a patch to clean up the call sites for FuncCall nodes, which
> I'd like to expand centrally rather than in each of the 37 (or 38, but
> I only redid 37) places where it's called. The remaining one is in
> src/backend/nodes/copyfuncs.c, which has to be modified for any
> changes in the that struct anyhow.
TBH, I don't think this is an improvement.
The problem with adding a new field to any struct is that you have to
run around and examine (and, usually, modify) every place that
manufactures that type of struct. With a makeFuncCall defined like
this, you'd still have to do that; it would just become a lot easier
to forget to do so.
If the subroutine were defined like most other makeXXX subroutines,
ie you have to supply *all* the fields, that argument would go away,
but the notational advantage is then dubious.
The bigger-picture point is that you're proposing to make the coding
conventions for building FuncCalls different from what they are for
any other grammar node. I don't think that's a great idea; it will
mostly foster confusion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2013-02-10 15:39:26 | Re: Department of Redundancy Department: makeNode(FuncCall) division |
Previous Message | Andrew Dunstan | 2013-02-10 15:03:40 | Re: JSON NULLs |