Re: Bug in pg_describe_object, patch v2
От | Robert Haas |
---|---|
Тема | Re: Bug in pg_describe_object, patch v2 |
Дата | |
Msg-id | AANLkTik2fK78Ogy98E+w9+ojtsJaWpi1cSNO32v4bZOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in pg_describe_object, patch v2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in pg_describe_object, patch v2
|
Список | pgsql-hackers |
On Thu, Jan 13, 2011 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> IMO, what this patch needs is to not output the types unless they are >>> actually different from the default (which can be inferred from the AM >>> type and the function arguments). That would fix my concern about it >>> emitting information that is 99.44% useless. > >> I guess we could do that, but I don't understand how you're supposed >> to infer them, which means probably a lot of other people won't >> either. > > Read the CREATE OPERATOR CLASS source code. (It likely would be best to > refactor that a bit so it would expose some way to obtain the implied > defaults --- I don't think that's done explicitly now, and it's > certainly not exported from opclasscmds.c.) I didn't say I *couldn't* take the time to understand this; I said I think it'd be more clear to more people if we just printed the types all the time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: