Re: Mimic ALIAS in Postgresql?

From: Jim Nasby <jim(dot)nasby(at)gmail(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Mimic ALIAS in Postgresql?
Date: 2024-01-16 21:03:33
Message-ID: 4db13aae-f1c5-4fc2-96e3-36216755d9ba@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 1/16/24 11:20 AM, 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;

Based on the schema names one possibility is that the aliases are there
as a pseudo-api between people/tools writing queries and the base
tables. IE: if you needed to make a (maybe backwards-incompatible)
change to "sometable" you now at least have the option of creating a
MTQRY.sometable *view* that hides whatever change you're making to
MTUSER.sometable.

In any case, yes, an updatable view would provide equivalent behavior in
Postgres.
--
Jim Nasby, Data Architect, Austin TX

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Brad White 2024-01-16 21:10:09 replication not replicating
Previous Message Jim Nasby 2024-01-16 20:54:10 Re: pg_dump Running Slow