Re: makeAndExpr(), etc. confined to gram.y?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: makeAndExpr(), etc. confined to gram.y?
Date: 2014-06-25 15:46:50
Message-ID: 75753.1403711210@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Wed, Jun 25, 2014 at 1:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
>>> Is there a reason why they've been left out of
>>> makefuncs.h/makefuncs.c? Perhaps they are not supposed to be used
>>> outside gram.y at all? For example, previously a caller (potentially)
>>> outside parser could do a makeA_Expr(AEXPR_AND, ...). I guess this is
>>> no longer possible with AEXPR_AND gone?

>> What would be the purpose? There is noplace except gram.y that builds
>> raw parse trees.

> Yeah, that is true. Sorry, I am unaware as to how generic make*
> functions in gram.y are and how they differ from those in makefuncs.c.

> So, use of make* family of functions outside parser is their abuse in
> some way? Anything that needs to use these functions should somehow be
> accomplished in parser perhaps. For example, duplicate/redundant CHECK
> expressions elimination and such?

Well, the larger point here is that those functions are specific to
gram.y's problem of constructing multi-AND(OR) structures during a series
of binary production actions. I don't see that there's any use for them
elsewhere, and the way that they modify the input structures wouldn't
necessarily be safe anywhere else either.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-06-25 15:52:41 Re: Allowing NOT IN to use ANTI joins
Previous Message Robert Haas 2014-06-25 15:44:57 Re: RLS Design