Re: proposal: function parse_ident

On 8/19/15 7:22 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@bluetreble.com> writes:
>>> 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.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com