"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> On Mon, Jun 29, 2015 at 4:27 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> ... So what you wrote here is equivalent to
>>
>> SELECT MIN(CAL_DATE),MAX(CAL_DATE) ::date, last_weekend::date INTO
>> first_weekend FROM sys.calendar ...
> â??Does it help to recognize the fact that "first_weekend::â??date" is not a
> valid identifier name (because it is lacking double-quotes)?
No. You're supposing that we *should* reject this case, which is not
true given the current rules. As a counterexample consider
SELECT INTO x - y FROM foo
which per current rules means
SELECT - y INTO x FROM foo
The only real difference between this and the :: case is that :: doesn't
come in a prefix-operator form, but that's an awfully weak reed to hang
a cross-language syntax rule on.
>> To make this noticeably better, we'd probably have to insist that
>> INTO come at the end of the SELECT list,
> Are you missing a "not" here?
No, I'm not. See previous example. To detect errors more completely,
we'd need a rule that what follows the INTO clause be "FROM" and nothing
else (well, maybe "GROUP BY" and some other cases, but in any case a fully
reserved word). As things stand, to support INTO-someplace-else we have
to suppose that anything other than identifiers and commas is not part of
INTO but belongs to the SELECT expression list. It's precisely the lack
of any clear delimiter between INTO's arguments and the main SELECT syntax
that is biting us, and as long as we allow INTO somewhere other than after
the SELECT expression list, we can't have a delimiter because of the
historical choice not to.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
