(2010/06/14 22:11), Robert Haas wrote: > On Mon, Jun 14, 2010 at 8:46 AM, Stephen Frost<sfr...@snowman.net> wrote: >> * Robert Haas (robertmh...@gmail.com) wrote: >>> 2010/6/14 KaiGai Kohei<kai...@ak.jp.nec.com>: >>>> It adds makeRangeTblEntry() into makefuncs.c to keep the code more >>>> clean. It shall be also used for the upcoming DML refactor patch. >>>> In this refactoring, a common DML permission checker function take >>>> a list of RangeTblEntry, so the caller has to set up the object. >>> >>> I think this is the epitome of pointless. It looks to me like this >>> just makes the code harder to read and very slightly slower without >>> actually accomplishing any useful abstraction. >> >> I had suggested to KaiGai that he check if there was an existing >> function for creating an RTE rather than just malloc'ing it- he took >> that to mean he should add one if he couldn't find one. Wasn't my >> intent, but by the same token I didn't see it as a terribly bad thing >> either. Perhaps it should be improved or maybe we should just rip it >> out, but I rather prefer some kind of abstraction for that given it's >> use in a number of places. Of course, I may just be overly thinking it. > > Well, there's not much point in having a function that initializes ONE > member of a 20+ member structure and leaves the initialization of all > the rest to the caller. The structure effectively functions like a > disjoint union, so maybe there'd be some value in having a function > for "build a relation RTE", which would set the rtekind to > RTE_RELATION and take arguments for the other fields that pertain to > that case. But the generic function proposed here doesn't really > provide any meaningful abstraction. > Yes, it is fact that I hesitated about what fields should be initialized at the makeRangeTblEntry(), because it has more than 20 members but most of them are meaningful only when rtekind has a certain code.
OK, at least, priority of the patch is not higher than others for me. I'll cancel the patch submission. Thanks, -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
