Postgres Pro
Downloads
Home   >   mailing lists

Re: proposal: function parse_ident - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: function parse_ident
Date
Msg-id CAFj8pRCSDQZ-DXJzOfXCQhvU7dUn5KKVbLwdH0tmx6e996VJNA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: function parse_ident  (Andres Freund <andres@anarazel.de>)
Responses Re: proposal: function parse_ident  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Tree view

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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: On-demand running query plans using auto_explain and signals
Next
From: Tatsuo Ishii
Date:
Subject: Re: BRIN INDEX value