Re: functional call named notation clashes with SQL feature
От | Tom Lane |
---|---|
Тема | Re: functional call named notation clashes with SQL feature |
Дата | |
Msg-id | 3882.1274979589@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: functional call named notation clashes with SQL feature (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: functional call named notation clashes with SQL feature
Re: functional call named notation clashes with SQL feature |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Peter Eisentraut wrote: >> In systems that have inheritance of composite types, this is used to >> specify which type the value is supposed to be interpreted as (for >> example, to treat the value as a supertype). Why don't they just use CAST() syntax for that, instead of adding this unnecessary syntax wart? If their complaint is that CAST() is too much typing, perhaps they could adopt :: cast notation ;-) > I think we should fix it now. Quick thought: maybe we could use FOR > instead of AS: select myfunc(7 for a, 6 for b); I'm afraid FOR doesn't work either; it'll create a conflict with the spec-defined SUBSTRING(x FOR y) syntax. regards, tom lane
В списке pgsql-hackers по дате отправления: