Re: to_regtype() Raises Error
От | Chapman Flack |
---|---|
Тема | Re: to_regtype() Raises Error |
Дата | |
Msg-id | 29bf28007033dc0cd4bf622bc6f194ea@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: to_regtype() Raises Error ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: to_regtype() Raises Error
|
Список | pgsql-hackers |
On 2023-09-17 21:58, David G. Johnston wrote: > ambiguity possible when doing that though: > > create type "interval second" as (x int, y int); > select to_regtype('interval second'); --> interval Not ambiguity really: that composite type you just made was named with a single <delimited identifier>, which is one token. (Also, being delimited makes it case-sensitive, and always distinct from an SQL keyword; consider the different types char and "char". Ah, that SQL committee!) The argument to regtype there is a single, case-insensitive, <regular identifier>, a <separator>, and another <regular identifier>, where in this case the first identifier happens to name a type, the second one happens to be a typmod, and the separator is rather simple as <separator> goes. In this one, both identifiers are part of the type name, and the separator a little more flamboyant. select to_regtype('character /* hi! am I part of the type name? /* what, me too? */ ok! */ -- huh! varying'); to_regtype ------------------- character varying As the backend already has one parser that knows all those lexical and grammar productions, I don't imagine it would be very appealing to have a second implementation of some of them. Obviously, to_regtype could add some simplifying requirements (like "only whitespace for the separator please"), but as you see above, it currently doesn't. Regards, -Chap
В списке pgsql-hackers по дате отправления: