Re: Query::targetList and RETURNING

From: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Query::targetList and RETURNING
Date: 2009-11-10 15:46:46
Message-ID: 4AF98AE6.2010807@cs.helsinki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
>> Tom Lane wrote:
>>> This doesn't really seem like a good idea from here. You're changing
>>> a decision that has something like twenty years' standing in the code,
>>> for no real gain. AFAICS this is just going to move the special cases
>>> from point A to point B.
>
>> Right, but this way you only have to special-case in grouping_planner(),
>> and targetList always means the same thing.
>
> If you think that, it just means you have not found all the places you
> need to special-case ;-). One really obvious example is ruleutils.c,
> and I rather imagine there are multiple places in the parser and
> rewriter that would need attention, quite aside from whatever it does
> to the planner.

Of course there were multiple places that needed attention, but those
don't look like special-casing to me, they just have to make sure to do
what they need to on the correct list of those two, which is what they
did before.

I wouldn't care for this at all, but with things the way they are right
now, the writeable CTE patch has to do quite a few of these:

List *cteList;
if (query->cmdType != CMD_SELECT)
cteList = query->returningList;
else
cteList = query->targetList;

/* do something with cteList */

With this patch, they could use targetList directly without paying any
attention to the type of the Query inside them.

Regards,
Marko Tiikkaja

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-10 16:02:24 Re: Query::targetList and RETURNING
Previous Message Kevin Grittner 2009-11-10 15:11:49 Re: Parsing config files in a directory