Mimic ALIAS in Postgresql?

On 1/16/24 09: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.

Just to be clear the table name <sometable> is the same in each schema,
correct?

In other words setting search_path would only help if was set per
session depending on which schema.<sometable> you wanted to access.

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;

--
Adrian Klaver
adrian.klaver@aklaver.com

On 1/16/24 09: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).

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

Assuming sometable is the same name in both schemas then the above will
not work as:

https://www.postgresql.org/docs/current/sql-createview.html

"The name of the view must be distinct from the name of any other
relation (table, sequence, index, view, materialized view, or foreign
table) in the same schema."

You would get a conflict with the existing table MTQRY.sometable.

Though I noticed you have both MTQRY and MYQRY referring to the same
thing, I think.

--
Adrian Klaver
adrian.klaver@aklaver.com

On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 1/16/24 09: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).

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

Assuming sometable is the same name in both schemas then the above will
not work as:

https://www.postgresql.org/docs/current/sql-createview.html

"The name of the view must be distinct from the name of any other
relation (table, sequence, index, view, materialized view, or foreign
table) in the same schema."

You would get a conflict with the existing table MTQRY.sometable.

CREATE VIEW mtqry.sometable AS SELECT * FROM mtuser.sometable;

But mtqry is not the same schema as mtuser..

dba=# create schema mtuser;
CREATE SCHEMA
dba=# create schema mtqry;
CREATE SCHEMA
dba=#
dba=# create table mtuser.sometable(f1 int);
CREATE TABLE
dba=#
dba=# create view mtqry.sometable as select * from mtuser.sometable;
CREATE VIEW

But what are the down-sides that I haven't thought of?

On 1/16/24 10:11 AM, Ron Johnson wrote:

On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver
<adrian.klaver@aklaver.com> wrote:

On 1/16/24 09: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).

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

Assuming sometable is the same name in both schemas then the above
will
not work as:

https://www.postgresql.org/docs/current/sql-createview.html

"The name of the view must be distinct from the name of any other
relation (table, sequence, index, view, materialized view, or foreign
table) in the same schema."

You would get a conflict with the existing table MTQRY.sometable.

CREATE VIEW mtqry.sometable AS SELECT * FROM mtuser.sometable;

But mtqry is not the same schema as mtuser..

dba=# create schema mtuser;
CREATE SCHEMA
dba=# create schema mtqry;
CREATE SCHEMA
dba=#
dba=# create table mtuser.sometable(f1 int);
CREATE TABLE
dba=#
dba=# create view mtqry.sometable as select * from mtuser.sometable;
CREATE VIEW

But what are the down-sides that I haven't thought of?

What happened to the MYQRY schema in your OP?

In the above you still have a relation with the same name in different
schema.

How does that change the issue?

On Tue, Jan 16, 2024 at 2:24 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 1/16/24 10:11 AM, Ron Johnson wrote:

On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:

On 1/16/24 09: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).

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

Assuming sometable is the same name in both schemas then the above will
not work as:

https://www.postgresql.org/docs/current/sql-createview.html

"The name of the view must be distinct from the name of any other
relation (table, sequence, index, view, materialized view, or foreign
table) in the same schema."

You would get a conflict with the existing table MTQRY.sometable.

CREATE VIEW mtqry.sometable AS SELECT * FROM mtuser.sometable;

But mtqry is not the same schema as mtuser..

dba=# create schema mtuser;
CREATE SCHEMA
dba=# create schema mtqry;
CREATE SCHEMA
dba=#
dba=# create table mtuser.sometable(f1 int);
CREATE TABLE
dba=#
dba=# create view mtqry.sometable as select * from mtuser.sometable;
CREATE VIEW

But what are the down-sides that I haven't thought of?

What happened to the MYQRY schema in your OP?

?

In the above you still have a relation with the same name in different
schema.

Yes. That's the whole point.

How does that change the issue?

I'm asking how to mimic table aliases, where a table is in MTUSER, but --
via the mechanism of aliases -- can be referenced from schema MTQRY.

On 1/16/24 11:40 AM, Ron Johnson wrote:

On Tue, Jan 16, 2024 at 2:24 PM Adrian Klaver
<adrian.klaver@aklaver.com> wrote:

On 1/16/24 10:11 AM, Ron Johnson wrote:

On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver
<adrian.klaver@aklaver.com> wrote:

On 1/16/24 09: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).

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

Assuming sometable is the same name in both schemas then the
above will
not work as:

https://www.postgresql.org/docs/current/sql-createview.html

"The name of the view must be distinct from the name of any other
relation (table, sequence, index, view, materialized view, or
foreign
table) in the same schema."

You would get a conflict with the existing table MTQRY.sometable.

CREATE VIEW mtqry.sometable AS SELECT * FROM mtuser.sometable;

But mtqry is not the same schema as mtuser..

dba=# create schema mtuser;
CREATE SCHEMA
dba=# create schema mtqry;
CREATE SCHEMA
dba=#
dba=# create table mtuser.sometable(f1 int);
CREATE TABLE
dba=#
dba=# create view mtqry.sometable as select * from mtuser.sometable;
CREATE VIEW

But what are the down-sides that I haven't thought of?

What happened to the MYQRY schema in your OP?

?

"... with two schemas: MTUSER and MTQRY. For example, sometimes refer to
MTUSER.sometable and other times refer to it as MYQRY.sometable.

"

Now if MYQRY.sometable in your OP is in fact MTQRY.sometable then this:

create view mtqry.sometable as select * from mtuser.sometable;

is not going to work as a view cannot have the same name as a table in
the same schema.

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

On Tue, 16 Jan 2024, 17:21 Ron Johnson, <ronljohnsonjr@gmail.com> 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;

I think views will work. Alternative might be interpose a proxy to rewrite
the SQL. https://www.galliumdata.com/ gives you an idea of what this might
look like although could do a lite version yourself.

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.

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... 😁

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.

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. 😞

On 1/16/24 4:57 PM, Rob Sargent wrote:

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.

Reality is that basically all modern (as in last 20 years) SQL access is
via frameworks that all use their own language and come up with SQL
based on that. How hard it'd be to bulk change the schema depends
entirely on the framework.
--
Jim Nasby, Data Architect, Austin TX

On 1/16/24 17:03, Ron Johnson wrote:

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. 😞

You could lie to DEV  and say the smart people on the pg list suggest
sed ;).  Better yet tell his PM!

On 1/16/24 17:39, Jim Nasby wrote:

On 1/16/24 4:57 PM, Rob Sargent wrote:

    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.

Reality is that basically all modern (as in last 20 years) SQL access
is via frameworks that all use their own language and come up with SQL
based on that. How hard it'd be to bulk change the schema depends
entirely on the framework.

Hm, it's a string /somewhere/.  The rest of this thread might be accused
of adding to the problem.

On 1/16/24 6:41 PM, Rob Sargent wrote:

On 1/16/24 17:39, Jim Nasby wrote:

On 1/16/24 4:57 PM, Rob Sargent wrote:

    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.

Reality is that basically all modern (as in last 20 years) SQL access
is via frameworks that all use their own language and come up with SQL
based on that. How hard it'd be to bulk change the schema depends
entirely on the framework.

Hm, it's a string /somewhere/.  The rest of this thread might be accused
of adding to the problem.

No, it's not, at least not as a complete SQL statement. See [1] as an
example of how this works in Ruby on Rails. Most modern frameworks work
in a similar fashion: you DON'T write raw SQL, or anything that looks
anything like it. In fact, many (most?) of these frameworks make it
difficult to do anything in raw SQL because it completely breaks the
paradigm of the framework.

Note that I'm talking about *frameworks*, not languages. But since most
languages require huge amounts of boilerplate to create a web service or
website it's not surprising that pretty much everyone uses frameworks.
(Go is actually an interesting exception to this.)

1: https://guides.rubyonrails.org/active_record_querying.html#find
--
Jim Nasby, Data Architect, Austin TX

On 1/17/24 16:25, Jim Nasby wrote:

On 1/16/24 6:41 PM, Rob Sargent wrote:

On 1/16/24 17:39, Jim Nasby wrote:

On 1/16/24 4:57 PM, Rob Sargent wrote:

    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.

Reality is that basically all modern (as in last 20 years) SQL
access is via frameworks that all use their own language and come up
with SQL based on that. How hard it'd be to bulk change the schema
depends entirely on the framework.

Hm, it's a string /somewhere/.  The rest of this thread might be
accused of adding to the problem.

No, it's not, at least not as a complete SQL statement. See [1] as an
example of how this works in Ruby on Rails. Most modern frameworks
work in a similar fashion: you DON'T write raw SQL, or anything that
looks anything like it. In fact, many (most?) of these frameworks make
it difficult to do anything in raw SQL because it completely breaks
the paradigm of the framework.

Note that I'm talking about *frameworks*, not languages. But since
most languages require huge amounts of boilerplate to create a web
service or website it's not surprising that pretty much everyone uses
frameworks. (Go is actually an interesting exception to this.)

1: https://guides.rubyonrails.org/active_record_querying.html#find

You may well be correct, but I have to ask the OP (Ron) if this is the
case in the current situation.  I find it difficult to conceive of a
"framework" apparently arbitrarily flipping between the alias and the
base name. (I read "For example, sometimes" as arbitrarily.)  The few
database frameworks with which I'm familiar would tolerate the coder
using either name.  And indeed in those (hibernate, mybatis, jOOQ) the
coder would be the one choosing the /nom du jour/.

On Mon, Jan 22, 2024 at 6:40 PM Rob Sargent <robjsargent@gmail.com> wrote:

On 1/17/24 16:25, Jim Nasby wrote:

On 1/16/24 6:41 PM, Rob Sargent wrote:

On 1/16/24 17:39, Jim Nasby wrote:

On 1/16/24 4:57 PM, Rob Sargent wrote:

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.

Reality is that basically all modern (as in last 20 years) SQL access is
via frameworks that all use their own language and come up with SQL based
on that. How hard it'd be to bulk change the schema depends entirely on the
framework.

Hm, it's a string /somewhere/. The rest of this thread might be accused
of adding to the problem.

No, it's not, at least not as a complete SQL statement. See [1] as an
example of how this works in Ruby on Rails. Most modern frameworks work in
a similar fashion: you DON'T write raw SQL, or anything that looks anything
like it. In fact, many (most?) of these frameworks make it difficult to do
anything in raw SQL because it completely breaks the paradigm of the
framework.

Note that I'm talking about *frameworks*, not languages. But since most
languages require huge amounts of boilerplate to create a web service or
website it's not surprising that pretty much everyone uses frameworks. (Go
is actually an interesting exception to this.)

1: https://guides.rubyonrails.org/active_record_querying.html#find

You may well be correct, but I have to ask the OP (Ron) if this is the
case in the current situation. I find it difficult to conceive of a
"framework" apparently arbitrarily flipping between the alias and the base
name. (I read "For example, sometimes" as arbitrarily.) The few database
frameworks with which I'm familiar would tolerate the coder using either
name. And indeed in those (hibernate, mybatis, jOOQ) the coder would be
the one choosing the /nom du jour/.

I don't know what, if any, framework the developer uses.