From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "jacktby(at)gmail(dot)com" <jacktby(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: can you give me a sql example to explain this? |
Date: | 2022-10-25 15:18:44 |
Message-ID: | CAKFQuwYHJeZvpdmGk0q+ESHs0tGY3N1iv34PbN6c2DajA5d-og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Oct 25, 2022 at 7:54 AM jacktby(at)gmail(dot)com <jacktby(at)gmail(dot)com> wrote:
> /*
> * In a "leaf" node representing a VALUES list, the above fields are all
> * null, and instead this field is set. Note that the elements of the
> * sublists are just expressions, without ResTarget decoration. Also note
> * that a list element can be DEFAULT (represented as a SetToDefault
> * node), regardless of the context of the VALUES list. It's up to parse
> * analysis to reject that where not valid.
> */
> List *valuesLists; /* untransformed list of expression lists */
>
> I need to understand what this is used for?
>
That's a fairly broad question...does this help?
In the SQL command:
VALUES ('one', 'two', 1+2, DEFAULT)
The valuesLists List will effectively contain three elements, {'one'},
{'two'}, {1+2}, and {DEFAULT}.
Though if it contains DEFAULT and the VALUES is not part of an INSERT an
error should eventually occur during parse analysis since a plain VALUES
command has no context from which to retrieve a default.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-10-25 15:22:44 | Re: please give me select sqls examples to distinct these! |
Previous Message | jacktby@gmail.com | 2022-10-25 14:54:37 | can you give me a sql example to explain this? |