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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Amit Langote <amitlangote09@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jun 25, 2014 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Langote <amitlangote09@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
On Wed, Jun 25, 2014 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Langote <amitlangote09@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 26, 2014 at 12:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Langote <amitlangote09@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers