On Wed, Sep 02, 2009 at 02:41:32PM -0500, Kevin Grittner wrote:
> Sam Mason <sam@samason.me.uk> wrote:
>
> > I'd always thought '2001-01-01' was a valid date literal, seems the
> > standard has required it to be prefixed by DATE at least back to
> > SQL92.
>
> Yep. I don't know if it would be remotely feasible, but the
> implementation which seems like it would be "standard-safe" but still
> give reasonable concessions to those wanting to skip the extra
> keystrokes of declaring the type of literals which are not character
> based would be to go with the suggestion of having a character string
> literal type, and change the semantics such that if there is a valid
> interpretation of the statement with the character string literal
> taken as text, it should be used; if not, resolve by current "unknown"
> rules. Probably not feasible, but it seems likely it would make
> everyone reasonably happy if it could be done.
Sounds as though that'll introduce more ambiguity into the system than
there is already.
> That leaves the issue of NULL being forced to type text in the absence
> of any type info in CASE, COALESCE, and NULLIF. If there were a way
> to say that these could return unknown type, that would be solved.
> That doesn't seem as though it would be likely to be massively
> difficult, although I could be wrong about that.
Would be nice and I'd love it to work like this, but it's quite a big
change I think. Currently, once PG has decided on a type it sticks with
it against all further evidence. Another example:
SELECT NULL AS c UNION SELECT '1' UNION SELECT 2;
Once you're doing the above you're into the world of full parametric
polymorphism and you're having to do much more complicated things at the
type level. When my free time becomes infinite I'll have a chance!
--
Sam http://samason.me.uk/
