From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: function parse_ident |
Date: | 2015-08-21 05:15:11 |
Message-ID: | CAFj8pRBLyLaqHTPaeuxrRKoPnmcbr_GLzUeG=ZFkGwG8WUj7Og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Pavel
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-08-21 05:47:50 | Re: Declarative partitioning |
Previous Message | Pavel Stehule | 2015-08-21 05:00:26 | Re: proposal: contrib module - generic command scheduler |