Gavin Sherry <[EMAIL PROTECTED]> writes:
> Is this intentional:
> template1=# values(1), (2);
> column1
> -
>1
>2
> (2 rows)
You bet. VALUES is parallel to SELECT in the SQL grammar, so AFAICS
it should be legal anywhere you can write SELECT.
The basic productions in th
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look over some
more if you
Joe Conway <[EMAIL PROTECTED]> writes:
> Good feedback -- thanks! But without the RTE, how would VALUES in the
> FROM clause work?
Is it different from INSERT? I'm just imagining a Values node in
the jointree and nothing in the rangetable.
If I'm reading the spec correctly, VALUES is exactly pa
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There are basically two ways you could go about this:
>> 1. Make a new jointree leaf node type to represent a VALUES construct,
>> and dangle the list of lists of expressions off that.
>> 2. Make a new RangeTblEntry type to represent a VAL
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm liking this too. But when you say "jointree node", are you saying to
model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
are referred to as "join nodes" in ExecInitNode. Or as you mentioned a
couple of times, should
