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

From Sam Mason
Subject Re: COALESCE and NULLIF semantics
Date
Msg-id 20090911230153.GT5407@samason.me.uk
Whole thread Raw
In response to Re: COALESCE and NULLIF semantics  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Fri, Sep 11, 2009 at 12:41:21PM -0500, Kevin Grittner wrote:
> Sam Mason <sam@samason.me.uk> wrote:
>  
> > what you you want is full type-inference as it's only that which
> > will allow you to track back up the layers and assign consistent
> > types to arbitrary expressions like the above.
>  
> Well, obviously that would fix it; I'm not clear on why *only* that
> would fix it.

Because, I think, if you did come up with "another" solution and gave it
another name most type-theorists would call it type-inference anyway.

Type inference is just a general idea and is implemented in lots of
different ways depending on the specifics of the problem.  You could
argue that PG has a limited form of type inference already.

> It seemed to me that we wouldn't have to go back up
> like that if we deferred the assignment of a type in conditional
> expressions.  I've only scanned that part of the code, so it's well
> within the range of possibility that I misunderstood something, but I
> thought the type assigned to a CASE or COALESCE is used in the context
> of evaluating enclosing expressions on the way *down*, no?

Maybe we're using different terms; but when a literal is declared you
don't know what type it is, just that it needs at most one.  It's only
later on when the variable is actually used that you find out what its
type constraints are.

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


pgsql-hackers by date:

Previous
From: Emmanuel Cecchet
Date:
Subject: Re: COPY enhancements
Next
From: Josh Berkus
Date:
Subject: Re: COPY enhancements