Re: pg_operator.oprcode in 9.2rc1
От | Tom Lane |
---|---|
Тема | Re: pg_operator.oprcode in 9.2rc1 |
Дата | |
Msg-id | 27380.1346352963@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_operator.oprcode in 9.2rc1 (Joe Abbate <jma@freedomcircle.com>) |
Список | pgsql-hackers |
Joe Abbate <jma@freedomcircle.com> writes: > Yes, I suspected that an OID was stored. What I'd still quibble with is > the use of the ambiguous regproc in pg_operator (also pg_type) and the > still-ambiguous schema-qualified proc name. I guess it's not feasible > (at least, short term), but it'd be preferable to store a "raw" OID and > let the user cast to regprocedure (or change the 'regproc' to > 'regprocedure'). Yeah, ideally those columns would be regprocedure. There are bootstrapping problems involved though with populating the initial contents of the catalogs during initdb --- the regprocedure input function doesn't work in that environment. (It might be possible to hack something for pg_operator, but the circularity is rather fundamental for loading pg_type, since the input function would need to consult pg_type to make sense of argument types.) In the meantime I'd suggest casting the columns to regprocedure when querying, if you want unambiguous results. That's what pg_dump does. Or you can cast to OID if you like numbers. regards, tom lane
В списке pgsql-hackers по дате отправления: