Tom Lane wrote:
> BTW, I looked at the problem a little bit and concluded that it wouldn't
> be so invasive to fix as all that. The weak spot at the moment is that
> parse_coerce() passes typmod -1 instead of the specified typmod to the
> datatype's input routine when converting an unknown-type literal. It
> has to do that to get the right behavior for varchar(N) and char(N)
> ... but we could imagine hacking it to behave differently for interval.
> At the most grotty,
>
> if (targetTypeId == INTERVALOID)
> pass targetTypeMod;
> else
> pass -1;
>
> but maybe something cleaner could be devised. That would take care of
> getting the info to interval_in(), and then the question is what
> interval_in() should do with it. Your notes in the TODO entry look
> like they summarize previous discussion accurately.
>
> It's worth pointing out that this would also affect data input, eg
> COPY into an interval column would interpret '100' differently depending
> on how the column had been declared. I think this is OK but it'd need
> some consideration.
>
> Actually implementing this is left as a task for someone who feels like
> hacking on the datetime code ... I don't particularly ...
I think this is a perfect project for Summer of Code.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
