Re: AW: Cast INTEGER to BIT confusion

> On 15/08/2023 14:02 CEST [Quipsy] Markus Karg <karg(at)quipsy(dot)de> wrote:
>
> I just tried out your proposal on PostgreSQL 15.3 and this is the result:
>
> ERROR: column "c" is of type bit but expression is of type integer
> LINE 5: INSERT INTO t VALUES (1);
> ^
> HINT: You will need to rewrite or cast the expression.
>
> Apparently the search path is ignored?!
>
> -----Ursprüngliche Nachricht-----
> Von: Erik Wienhold <ewie(at)ewie(dot)name>
> Gesendet: Dienstag, 15. August 2023 13:48
> An: [Quipsy] Markus Karg <karg(at)quipsy(dot)de>; pgsql-general(at)lists(dot)postgresql(dot)org
> Betreff: Re: Cast INTEGER to BIT confusion
>
> 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:
>
> =# CREATE SCHEMA xxx;
> =# CREATE DOMAIN xxx.bit AS int;
> =# SET search_path = xxx, pg_catalog;
> =# CREATE TABLE t (c bit);
> =# INSERT INTO t VALUES (1);
> INSERT 0 1
>
> But I would do that only if the third-party code cannot be tweaked because
> the custom domain could be confusing. It's also prone to errors as it relies
> on a specific search path order. Also make sure that regular users cannot
> create objects in schema xxx that would override objects in pg_catalog.

Hmm, I thought that Postgres resolves all types through the search path, but
apparently that is not the case for built-in types. I never used this to
override built-in types so this is a surprise to me. (And obviously I haven't
tested the search path feature before posting.)

Neither [1] or [2] mention that special (?) case or if there's a distinction
between built-in types and user-defined types. The USAGE privilege is required
according to [2] but I was testing as superuser anyway.

[1] https://www.postgresql.org/docs/15/ddl-schemas.html
[2] https://www.postgresql.org/docs/15/runtime-config-client.html#GUC-SEARCH-PATH

--
Erik