Re: the '::' cast doesn't work in the FROM clause
От | Alexey Klyukin |
---|---|
Тема | Re: the '::' cast doesn't work in the FROM clause |
Дата | |
Msg-id | B4AA1AAA-86F1-4ACC-B02D-0AB86C1A782D@commandprompt.com обсуждение исходный текст |
Ответ на | Re: the '::' cast doesn't work in the FROM clause (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: the '::' cast doesn't work in the FROM clause
|
Список | pgsql-bugs |
On Aug 29, 2011, at 5:47 PM, Tom Lane wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Merlin Moncure <mmoncure@gmail.com> wrote: >>> yeah, that's the correct way, but why does this work? >>> select val from random() as val; >=20 >> If you look at the PostgreSQL reference docs for the SELECT >> statement, a from_item can be a SELECT statement in parentheses or a >> function call (among other things). It cannot be an arbitrary >> expression containing operators (like ::). >=20 > Right. We also accept things that look syntactically like function > calls, so as to avoid debates with newbies about whether, say, > COALESCE(...) is a function or not. CAST() falls into that category, > while :: doesn't. I was wondering exactly why CAST() is permitted, while it's not a function = (in Kevin's example, texteq is a function) and the explanation above answer= s my question.=20 >=20 > There is actually a practical reason for this policy beyond the question > of whether CAST is a function call or not: the structure name(...) has > a well-defined syntactic extent, so there are no issues of operator > precedence to worry about when it's embedded in a larger construct. > IIRC, we ran into exactly that problem with the CREATE INDEX syntax, > which is why an expression index column has to be parenthesized unless > it looks like a function call. >=20 > So IMO there is no syntax bug here.=20=20 I agree, thank you and Kevin for the great explanation! > There is a dump/reload bug though :-( ... if you were to do >=20 > create view vv as select val from CAST(random() as integer) as val;=20 >=20 > you will find that the system prints it out with the :: syntax, > which won't work. Would it be acceptable/sufficient to output CAST(...) instead of '::' for= all casts in pg_dump to fix this problem, assuming that CAST can be used a= nywhere where '::' is accepted? -- Alexey Klyukin http://www.commandprompt.com The PostgreSQL Company =96 Command Prompt, Inc.
В списке pgsql-bugs по дате отправления: