| From: | Dirk Mika <Dirk(dot)Mika(at)mikatiming(dot)de> |
|---|---|
| To: | "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 08:57:01 |
| Message-ID: | 36BCEBBD-0EDD-4D37-897D-E2D3B3733050@mikatiming.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi
--
Dirk Mika
Software Developer
mika:timing GmbH
Strundepark - Kürtener Str. 11b
51465 Bergisch Gladbach
Germany
fon +49 2202 2401-1197
dirk(dot)mika(at)mikatiming(dot)de
www.mikatiming.de
AG Köln HRB 47509 * WEEE-Reg.-Nr. DE 90029884
Geschäftsführer: Harald Mika, Jörg Mika
## How2Use
## the ChampionChip by mika:timing
## https://youtu.be/qfOFXrpSKLQ
Am 04.07.19, 10:50 schrieb "rob stone" <floriparob(at)gmail(dot)com>:
Why don't you define "ratified" as CHAR(1)?
This will change the constraint to
Check constraints:
"ck_tp_ratified" CHECK (ratified IS NULL OR (ratified = ANY (ARRAY['Y'::bpchar, 'N'::bpchar])))
Less casting. (
Does the casting from one "String" type to another "String" type have any performance impact, btw?
AFAIK, constraint evaluation is based upon the column's underlying data
type.
But isn't char and varchar all stored in the same data structure?
Dirk
| From | Date | Subject | |
|---|---|---|---|
| Next Message | paul.malm | 2019-07-04 09:51:01 | Help with a selection |
| Previous Message | rob stone | 2019-07-04 08:49:59 | Re: Expression of check constraint |