On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule <pavel.stehule@gmail.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.
