Tom,
> Emergency fix? This operator didn't behave reasonably in 7.1 either
> (at least not by my definition of reasonable). What exactly would
> you have us do?
No, not you! For me to fix. You're a volunteer, as far as I'minvolved. I just wanted suggestions for a quick fix.
WhenI foundthe other issues, it was more reasonable to search-and-replace onvalues ("interval"() for interval() was
easy). I can't figure out howto pattern match on interval + timestamp, especially with variablesinvolved.
Is there a way, for example, that I could disallow the TIMESTAMP -->DATE implicit conversion in my code? That would
breakall thefunctions and views with this problem, and then I could identify them.
> Yah. Offhand I'd argue that no information-discarding conversion
> should be implicitly invokable. date->timestamp is fine;
> timestamp->date should require an explicit cast. I've already
> proposed
> that we add a flag to pg_proc to distinguish implicit from explicit
> conversion operations, and no one complained. But we have not yet
> begun to argue about exactly which conversions should be allowed
> implicitly...
Hey, feel free to take up the argument here, too! It is a SQL topic,after all ...
-Josh
______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete
informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small
businesses fax 621-2533 and non-profit organizations. San Francisco