2015-08-20 21:16 GMT+02:00 Jim Nasby <jim.na...@bluetreble.com>: > On 8/19/15 7:22 PM, Tom Lane wrote: > >> Jim Nasby <jim.na...@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.
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 >
