> Are you saying about (a, b, c) or about 'a_constant' ?
> Again, can someone comment on are they in standards or not ?
> Tom ?
> If yes then please add parser' support for them now...
As I mentioned a few minutes ago in my last message, I parse the row descriptors and
the subselects but for subselect expressions (e.g. "(a,b) OP (subselect)" I currently
ignore the result. I didn't want to pass things back as lists until something in the
backend was ready to receive them.
If it is OK, I'll go ahead and start passing back a list of expressions when a row
descriptor is present. So, what you will find is lexpr or rexpr in the A_Expr node
being a list rather than an atomic node.
Also, I can start passing back the subselect expression as the rexpr; right now the
parser calls elog() and quits.
btw, to implement "(a,b,c) OP (d,e,f)" I made a new routine in the parser called
makeRowExpr() which breaks this up into a sequence of "and" and/or "or" expressions.
If lists are handled farther back, this routine should move to there also and the
parser will just pass the lists. Note that some assumptions have to be made about the
meaning of "(a,b) OP (c,d)", since usually we only have knowledge of the behavior of
"a OP c". Easy for the standard SQL operators, unknown for others, but maybe it is OK
to disallow those cases or to look for specific appearance of the operator to guess
the behavior (e.g. if the operator has "<" or "=" or ">" then build as "and"s and if
it has "<>" or "!" then build as "or"s.
Let me know what you want...
- Tom