On 2015/12/27 3:11, Tom Lane wrote: > I wrote: >> Amit Langote <langote_amit...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
