Re: COALESCE and NULLIF semantics - Mailing list pgsql-hackers

From Sam Mason
Subject Re: COALESCE and NULLIF semantics
Date
Msg-id 20090909210003.GN5407@samason.me.uk
Whole thread Raw
In response to Re: COALESCE and NULLIF semantics  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: COALESCE and NULLIF semantics
List pgsql-hackers
On Wed, Sep 09, 2009 at 10:25:34AM -0400, Tom Lane wrote:
> Now admittedly there's probably not any major technical obstacle to
> making a runtime conversion happen --- it's merely delayed invocation of
> the destination type's input function.  But I find it really ugly from a
> theoretical point of view.  Doing calculations with "unknown" values
> just seems wrong.

It's pretty grim.  This seems to be some strange halfway house on the
way to real type-inference, with broken semantics to boot.  How would it
prevent weirdos like:
 SELECT 'msg'||v, date_trunc('year',v), v+10 FROM (SELECT 'hi ho') x(v);

If Kevin wants something like this it should either be real
type-inference or leave it as it is.  The problem is that each variable
should have exactly one type, type inference lets you delay finding that
type until later down the tree and then back-propagate it back up again.
Your suggestions seems to allow variables to have as many types as it
wants.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Ragged CSV import
Next
From: "Kevin Grittner"
Date:
Subject: Re: Ragged CSV import