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 up
> 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 way
> On 17/08/2023 09:31 CEST [Quipsy] Markus Karg wrote:
>
> 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
"[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 immediatel
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 se
