On Tue, Sep 8, 2015 at 8:57 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > > 2015-09-08 14:06 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > >> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule <pavel.steh...@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.
