Re: Simplifying OID lookups in the presence of namespaces
От | Tom Lane |
---|---|
Тема | Re: Simplifying OID lookups in the presence of namespaces |
Дата | |
Msg-id | 3768.1019533594@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Simplifying OID lookups in the presence of namespaces (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
Joe Conway <mail@joeconway.com> writes: > Tom Lane wrote: >> Also, for functions and operators the name alone is not sufficient to >> uniquely identify the object. Type regproc currently throws an error >> if asked to convert a nonunique function name; that severely limits its >> usefulness. I'm toying with allowing datatypes in the input string, >> eg >> 'sum(bigint)'::regproc >> but I wonder if this will create compatibility problems. In particular, >> should the regproc and regoperator output converters include datatype >> indicators in the output string? (Always, never, only if not unique?) > I'd be inclined to include datatype always. If you don't, how can you > use this for pg_dump, etc? pg_dump would probably actually prefer not having type info in the output string; it'll just have to strip it off in most places. But I don't have a good feeling for the needs of other applications, so I was asking what other people thought. If we supported both ways via two datatypes, we'd have all the bases covered; I'm just wondering if it's worth the trouble. regards, tom lane PS: interesting thought about enum ...
В списке pgsql-hackers по дате отправления: