Re: Department of Redundancy Department: makeNode(FuncCall) division

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

In response to

Responses

Browse pgsql-hackers by date

  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