From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Erik Wienhold <ewie(at)ewie(dot)name> |
Cc: | "[Quipsy] Markus Karg" <karg(at)quipsy(dot)de>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Cast INTEGER to BIT confusion |
Date: | 2023-08-17 13:26:15 |
Message-ID: | CAKFQuwZSzYDpPjPAHonewfRBHgjY5MBT0txdTtF2PHg4KoSKpQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday, August 15, 2023, Erik Wienhold <ewie(at)ewie(dot)name> wrote:
> > On 15/08/2023 10:49 CEST [Quipsy] Markus Karg <karg(at)quipsy(dot)de> wrote:
> >
> > Hello PostgreSQL Community,
> >
> > I like to store just a single bit but that can be either 1 or 0, so I
> tried
>
> You could create a custom domain if you're only interested in values 0 and
> 1
> and don't use bit string functions. The search path must be changed so
> that
> domain bit overrides pg_catalog.bit:
The table using the system bit type already exists and thus the oid for the
data type of the stored catalog column is that of the system bit type.
Creating a user bit domaim is going to have absolutely zero impact on this
situation.
If you really want to make this work and are willing to risk and deal with
side-effects of manual catalog updates you could maybe make the existing
cast implicit.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2023-08-17 13:31:44 | Re: AW: AW: Cast INTEGER to BIT confusion |
Previous Message | Tom Lane | 2023-08-17 13:18:14 | Re: AW: AW: Cast INTEGER to BIT confusion |