Re: Cast INTEGER to BIT confusion

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.

In response to

Browse pgsql-general by date

  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