| From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: COALESCE requires NULL from scalar subquery has a type |
| Date: | 2016-02-09 14:56:53 |
| Message-ID: | CAEzk6fd1g6SVrUYJPKNc5hA4DjX1CcCZFWEGMSQrQ=98sy1rGw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 9 February 2016 at 14:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> SELECT COALESCE((SELECT 'Yes' FROM gwtest WHERE id=4), 'No') AS valid;
>
> There's no null visible anywhere in that. I suppose that if there's
> no row with id=4, there would be a null at runtime,
Well yes, that was the whole point.
> but that's not
> going to make any difference for parse-time determination of what
> type the COALESCE() will return.
But when the gwtest subquery _does_ return a value it works, so the
problem can't be parse-time determination, can it?
Geoff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2016-02-09 15:16:29 | Re: COALESCE requires NULL from scalar subquery has a type |
| Previous Message | Tom Lane | 2016-02-09 14:53:02 | Re: COALESCE requires NULL from scalar subquery has a type |