> On 15/08/2023 14:02 CEST [Quipsy] Markus Karg <karg@xxxxxxxxx> 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@xxxxxxxxx> > Gesendet: Dienstag, 15. August 2023 13:48 > An: [Quipsy] Markus Karg <karg@xxxxxxxxx>; pgsql-general@xxxxxxxxxxxxxxxxxxxx > 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
