Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> We don't currently support that style of specifying interval constants,
>> and you shouldn't hold your breath expecting it to happen --- it will
>> require a whole bunch of abuse of the currently data-type-independent
>> processing of literal constants.
> I did some more research on this item, and updated the TODO item:
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 ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
