From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: COALESCE and NULLIF semantics |
Date: | 2009-09-11 23:01:54 |
Message-ID: | 20090911230153.GT5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 11, 2009 at 12:41:21PM -0500, Kevin Grittner wrote:
> Sam Mason <sam(at)samason(dot)me(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-09-11 23:04:30 | Re: COPY enhancements |
Previous Message | Emmanuel Cecchet | 2009-09-11 22:56:42 | Re: COPY enhancements |