From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Dirk Mika <Dirk(dot)Mika(at)mikatiming(dot)de>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Expression of check constraint |
Date: | 2019-07-04 10:32:04 |
Message-ID: | ea4efc94946a7e098786fa5a38c4d43f8da8871b.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dirk Mika wrote:
> if I add the following check constraint to a table:
>
> ALTER TABLE public.times_places
> ADD CONSTRAINT ck_tp_ratified CHECK
> (ratified IS NULL OR (ratified IN ('Y', 'N')));
>
> It becomes the following when describing the table in psql:
>
> Check constraints:
> "ck_tp_ratified" CHECK (ratified IS NULL OR (ratified::text = ANY (ARRAY['Y'::character varying, 'N'::character varying]::text[])))
>
> The behavior of the check constraint is logically identical and this seems plausible to me, but I still wonder why:
> 1. does the expression x in (a, b) become the expression x = any(array(a, b)?
Because that's what the PostgreSQL query parser makes out of an IN list.
> 2. why is the array expression casted so wildly? First to character varying and then to text[]?
Because "text" is the preferred string type, and there is no "=" operator for "character varying".
But don't worry, casting "character varying" to "text" doesn't cost anything, since the
types are binary coercible (the storage ist the same).
> 3. The column ratified is of type character varying(1). Why is it casted to text?
See 2. above.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Sychev | 2019-07-04 12:20:46 | Error: rows returned by function are not all of the same row type |
Previous Message | Dirk Mika | 2019-07-04 10:01:02 | Re: Help with a selection |