Search Postgresql Archives

AW: AW: Cast INTEGER to BIT confusion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am giving up. While even `SELECT current_schemas(true)` correctly prints `xxx, pg_catalog` it still uses the original bit type. This is completely NOT as described in the documentation, where it is clearly told that pg_catalog only is searched immediately if NOT found in the search path. It seems it is simply impossible to run this application on PostgreSQL, and we have to stick with a different RDBMS. Very sad.
-Markus


-----Ursprüngliche Nachricht-----
Von: Erik Wienhold <ewie@xxxxxxxxx> 
Gesendet: Dienstag, 15. August 2023 16:28
An: [Quipsy] Markus Karg <karg@xxxxxxxxx>; pgsql-general@xxxxxxxxxxxxxxxxxxxx
Betreff: Re: AW: Cast INTEGER to BIT confusion

> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux