Re: AW: AW: Cast INTEGER to BIT confusion

"[Quipsy] Markus Karg" <karg(at)quipsy(dot)de> writes:
> 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.

That's probably because the grammar uses SystemTypeName (effectively
prepending "pg_catalog.") for any type that has special syntax called
out in the SQL standard. You could get around that in various ways,
but they all involve changing the way the CREATE TABLE command is
written, because just plain "BIT" is a SQL-mandated special case.

> It seems it is simply impossible to run this application on PostgreSQL, and we have to stick with a different RDBMS. Very sad.

You could leave the type alone and instead fool with the properties of
the cast (see [1]). As superuser:

regression=# create table t (f1 bit);
CREATE TABLE
regression=# insert into t values (1);
ERROR: column "f1" is of type bit but expression is of type integer
LINE 1: insert into t values (1);
^
HINT: You will need to rewrite or cast the expression.
regression=# select * from pg_cast where castsource = 'integer'::regtype and casttarget = 'bit'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
-------+------------+------------+----------+-------------+------------
10186 | 23 | 1560 | 1683 | e | f
(1 row)

regression=# update pg_cast set castcontext = 'a' where castsource = 'integer'::regtype and casttarget = 'bit'::regtype;
UPDATE 1
regression=# select * from pg_cast where castsource = 'integer'::regtype and casttarget = 'bit'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
-------+------------+------------+----------+-------------+------------
10186 | 23 | 1560 | 1683 | a | f
(1 row)

regression=# insert into t values (1);
INSERT 0 1

The main disadvantage of this approach is you'd have to remember to
perform that UPDATE in any new database, since pg_dump wouldn't
preserve it for you.

On the whole though I think this project is a lost cause. If you
are insisting on bug-compatibility with non-SQL-compliant details
of some other DBMS, and you can't adjust the application at all,
there is going to be some new showstopper problem biting you
every day.

regards, tom lane

[1] https://www.postgresql.org/docs/current/catalog-pg-cast.html