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

Hi,

A recent commit titled "Avoid recursion when processing simple lists
of AND'ed or OR'ed clauses."
(2146f13408cdb85c738364fe8f7965209e08c6be) got rid of AEXPR_AND, etc.
and instead created makeAndExpr(), etc. in gram.y

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?

--
Amit

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.

regards, tom lane

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?

--
Amit

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

On Thu, Jun 26, 2014 at 12:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
>> 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.
>

I see. Thanks for clarifying.

--
Amit