Re: MergeAttributes type (mod) conflict error detail
От | Amit Langote |
---|---|
Тема | Re: MergeAttributes type (mod) conflict error detail |
Дата | |
Msg-id | 5680812D.4040907@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: MergeAttributes type (mod) conflict error detail (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2015/12/27 3:11, Tom Lane wrote: > I wrote: >> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes: >>> Any specific reason why it doesn't spell out typmods in the above detail >>> message? > >> * There's a rough policy in the parser to prefer TypeNameToString >> when complaining about a TypeName input, rather than reconstructing >> the type name from the OID. The reason for this is that we'd rather >> complain about the type name as entered, not the canonical type name >> --- for example, if the user typed "float8" it might be a bit confusing >> if the parser then complains about "double precision". >> >> I'm not entirely sure though that that argument should be applied >> to this particular case, because the other type referred to will >> certainly get displayed in canonical form. > > On reflection, I think trying to spell both types according to the same > rules will be the least confusing behavior here. > >> So we could either apply your patch as written, or we could replace >> only the format_type_be calls with format_type_with_typemod, and >> then fix TypeNameToString so that it will show the typmod if any. >> (We'd need to consider whether that behavior is OK for all callers.) >> >> Even if we decide this particular case is best handled by presenting >> canonical type names on both sides, maybe it would be wise to look >> into whether TypeNameToString should be changed for other callers. > > I looked through the other call sites for TypeNameToString and > TypeNameListToString. In none of them does it seem useful to include any > typmod info in the printout, and in many of them it would be positively > misleading (e.g., functions do not care about typmod decorations on their > argument types). So we should not change the behavior of those functions. > Perhaps down the road there'll be a use for "TypeNameAndTypmodToString", > but I don't feel a need for it today. > > So I am thinking your patch is good as proposed, ie, let's use > format_type_with_typemod here. I agree. Thanks for adding the tests. Regards, Amit
В списке pgsql-hackers по дате отправления: