On Thu, 17 Aug 2023 at 19:09, GF wrote:
>
> Erik,
> The could be a possible solution, if you could play with search_path...
>
>
(sorry, Erik, obviously my message was intended to Markus)
Erik,
The could be a possible solution, if you could play with search_path...
You could mirror all the original schema onto another one with views that
have the original table names.
For all tables that need some special treatment you can then write
instead-of triggers, while all other views are
> On 17/08/2023 15:18 CEST Tom Lane wrote:
>
> 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
det: Dienstag, 15. August 2023 16:28
> An: [Quipsy] Markus Karg ; pgsql-general@lists.postgresql.org
> Betreff: Re: AW: Cast INTEGER to BIT confusion
>
> > On 15/08/2023 14:02 CEST [Quipsy] Markus Karg wrote:
> >
> > I just tried out your proposal on PostgreSQL 15.3 an
"[Quipsy] Markus Karg" 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
Betreff: Re: AW: Cast INTEGER to BIT confusion
> On 15/08/2023 14:02 CEST [Quipsy] Markus Karg 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
> On 15/08/2023 14:02 CEST [Quipsy] Markus Karg 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
> On 15/08/2023 13:59 CEST [Quipsy] Markus Karg wrote:
>
> Is setting the search path something that has to be done for each new
> connection / each user, or is this something static and global for the
> database?
The search path is set per connection and the initial search path can be
Erik,
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
Thank you, Erik! Prefixing the search path in fact looks very interesting, and
I think in this particular application it is a safe (and the only) solution.
Is setting the search path something that has to be done for each new
connection / each user, or is this something static and global for
10 matches
Mail list logo
