From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MergeAttributes type (mod) conflict error detail |
Date: | 2015-12-28 00:24:13 |
Message-ID: | 5680812D.4040907@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/12/27 3:11, Tom Lane wrote:
> I wrote:
>> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-12-28 00:31:24 | Re: [PROPOSAL] VACUUM Progress Checker. |
Previous Message | Peter Geoghegan | 2015-12-27 22:20:30 | Minor additional changes to 9.5's INSERT documentation |