Re: proposal: function parse_ident

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: function parse_ident
Дата
Msg-id CAFj8pRCSDQZ-DXJzOfXCQhvU7dUn5KKVbLwdH0tmx6e996VJNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: function parse_ident  (Andres Freund <andres@anarazel.de>)
Ответы Re: proposal: function parse_ident  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers

2015-09-03 13:11 GMT+02:00 Andres Freund <andres@anarazel.de>:
On 2015-08-23 17:46:36 +0200, Pavel Stehule wrote:
> here is the patch
>
> It is really trivial - all heavy work was done done before.

This seems to entirely disregard the comments in
http://archives.postgresql.org/message-id/29030.1440030152%40sss.pgh.pa.us
about the fact that this approach only works for a few object types?


The alghoritm for parsing identifiers is same - the differences are in a names of levels, and in ending symbols.

I don't would to write totally generic parser - more without access to system catalog or without external hint, you cannot to decide if identifier is schema.table or table.column. But the rules for parsing is exactly same.

The function can be redesigned little bit:

FUNCTION parse_ident(OUT level1 text,OUT level2 text,OUT level3 text,OUT specific text)

so it can parse function myschema.myfunc(xx int)

level1: NULL
level2: myschema
level3: myfunc
specific: (xx int)

Is it acceptable?

Regards

Pavel



 
Also, for the umpteenst time: Start actually quoting in a sane manner.

Greetings,

Andres Freund

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: BRIN INDEX value