Re: proposal: function parse_ident

On Tue, Sep 8, 2015 at 8:57 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> 2015-09-08 14:06 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
>
>> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>> > 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?
>>
>> Well, *I* think that would be useful. I'm not sure it belongs in
>> core, but useful? Yeah, definitely. I would probably make it text[]
>> rather than level1, level2, level3, though.
>>
>
> Returning a array is a good idea.
>
>
>
+1

I would have immediate use for this. So often a function is written with a
table name as a parameter and it's not immediately clear if the schema is
to be parsed out of the string, prescribed, or a separate parameter...in
which case the function signature now has a clumsy optional schema
parameter somewhere. I've written this bit of code probably five times now,
let's make it a solved problem.

text[] return seems most sensible. While I can see the use for a record
output, it wouldn't be used as often.