Don't say "parse names for things other than tables". Only a minority of the types of objects used in the database have names that meet this specification.
Really? My impression is that almost everything that's not a shared object allows for a schema...
Tables meet this naming spec. Columns, functions, operators, operator classes/families, collations, constraints, and conversions do not (you need more data to name them). Schemas, databases, languages, extensions, and some other things also do not, because you need *less* data to name them. Types also don't really meet this naming spec, because you need to contend with special cases like "int[]" or "timestamp with time zone". So this proposal doesn't seem very carefully thought-through to me, or at least the use case is much narrower than it could be.
Also, if "object does not exist" isn't supposed to be an error case, what of "name is not correctly formatted"? It seems a bit arbitrary to me to throw an error in one case but not the other.
I think the important point here is this is *parse*_ident(). It's not meant to guarantee an object actually exists, what kind of object it is, or whether it's syntactically correct. It's meant only to separate an identifier into it's 3 (or in some cases 2) components. If this was as simple as string_to_array(foo, '.') then it'd be a bit pointless, but it's obviously a lot more complex than that.
parsing composite identifier is pretty complex - and almost all work is done - it just need SQL envelope only
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
