Re: Mimic ALIAS in Postgresql? - Mailing list pgsql-general

From Ron Johnson
Subject Re: Mimic ALIAS in Postgresql?
Date
Msg-id CANzqJaBJ=jgXsiaybG6UjyoJ8NbpYz6rPLS8EH6+0Pkm5HxoVw@mail.gmail.com
Whole thread Raw
In response to Re: Mimic ALIAS in Postgresql?  (Rob Sargent <robjsargent@gmail.com>)
Responses Re: Mimic ALIAS in Postgresql?
List pgsql-general
On Tue, Jan 16, 2024 at 5:57 PM Rob Sargent <robjsargent@gmail.com> wrote:
On 1/16/24 15:39, Ron Johnson wrote:
On Tue, Jan 16, 2024 at 5:31 PM Rob Sargent <robjsargent@gmail.com> wrote:
On 1/16/24 10:20, Ron Johnson wrote:
Some RDBMSs have CREATE ALIAS, which allows you to refer to a table by a different name (while also referring to it by the original name).

We have an application running on DB2/UDB which (for reasons wholly unknown to me, and probably also to the current developer) extensively uses this with two schemas: MTUSER and MTQRY.  For example, sometimes refer to MTUSER.sometable and other times refer to it as MYQRY.sometable.

My goal is to present a way to migrate from UDB to PG with as few application changes as possible.  Thus, the need to mimic aliases.

Maybe updatable views?
CREATE VIEW mtqry.sometable AS SELECT * FROM mtuser.sometable;

Isn't it time to get rid of that debt?  A sed -i 's/MTUSER/MTQRY/g' (or vice versa) ends what looks to me to be a split brain problem.  All the sql is in git right? :) 

Or perhaps you have to beef the sed up to use word boundaries just in case.

I'm not a Java web developer... 😁

You need to adjust you glasses if that's what you see me as.
 
You're the one who apparently sees me as having any control over anything except when the backups run. 😞

pgsql-general by date:

Previous
From: Brad White
Date:
Subject: Re: replication isn't replicating
Next
From: Ron Johnson
Date:
Subject: Re: replication not replicating