Re: COALESCE requires NULL from scalar subquery has a type

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: COALESCE requires NULL from scalar subquery has a type
Date: 2016-02-09 15:16:29
Message-ID: CAKFQuwYS+pt_zATmxDVbizBj+D6VsaFHsmWUFYb3g1s8M-1waA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Feb 9, 2016 at 7:56 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:

> 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?
>
>
SELECT COALESCE((SELECT 'Yes' FROM (VALUES (1),(2),(3)) tst (id) WHERE
id=2), 'No') AS valid;

​Same error...I tested using the table as well...also the same error for
values of id between 1 and 3.

​9.5.0

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Geoff Winkless 2016-02-09 15:21:10 Re: COALESCE requires NULL from scalar subquery has a type
Previous Message Geoff Winkless 2016-02-09 14:56:53 Re: COALESCE requires NULL from scalar subquery has a type