Re: proposal: function parse_ident

Hi

2015-08-21 7:15 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

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

here is the patch

It is really trivial - all heavy work was done done before.

Regards

Pavel

>
> Pavel
>
>
>>
>> --
>> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
>> Data in Trouble? Get it in Treble! http://BlueTreble.com
>>
>
>