Re: Mimic ALIAS in Postgresql?
On Mon, Jan 22, 2024 at 6:40 PM Rob Sargent 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.
Re: Mimic ALIAS in Postgresql?
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/.
Re: Mimic ALIAS in Postgresql?
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
Re: Mimic ALIAS in Postgresql?
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.
Re: Mimic ALIAS in Postgresql?
On 1/16/24 17:03, Ron Johnson wrote: On Tue, Jan 16, 2024 at 5:57 PM Rob Sargent wrote: On 1/16/24 15:39, Ron Johnson wrote: On Tue, Jan 16, 2024 at 5:31 PM Rob Sargent 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!
Re: Mimic ALIAS in Postgresql?
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
Re: Mimic ALIAS in Postgresql?
On Tue, Jan 16, 2024 at 5:57 PM Rob Sargent wrote: > On 1/16/24 15:39, Ron Johnson wrote: > > On Tue, Jan 16, 2024 at 5:31 PM Rob Sargent 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. 😞
Re: Mimic ALIAS in Postgresql?
On 1/16/24 15:39, Ron Johnson wrote: On Tue, Jan 16, 2024 at 5:31 PM Rob Sargent 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.
Re: Mimic ALIAS in Postgresql?
On Tue, Jan 16, 2024 at 5:31 PM Rob Sargent 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... 😁
Re: Mimic ALIAS in Postgresql?
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.
Re: Mimic ALIAS in Postgresql?
On Tue, 16 Jan 2024, 17:21 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; > 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. >
Re: Mimic ALIAS in Postgresql?
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
Re: Mimic ALIAS in Postgresql?
On 1/16/24 11:40 AM, Ron Johnson wrote: On Tue, Jan 16, 2024 at 2:24 PM Adrian Klaver wrote: On 1/16/24 10:11 AM, Ron Johnson wrote: On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver 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.
Re: Mimic ALIAS in Postgresql?
On Tue, Jan 16, 2024 at 2:24 PM Adrian Klaver wrote: > > On 1/16/24 10:11 AM, Ron Johnson wrote: > > On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver > 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.
Re: Mimic ALIAS in Postgresql?
On 1/16/24 10:11 AM, Ron Johnson wrote: On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver 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?
Re: Mimic ALIAS in Postgresql?
On Tue, Jan 16, 2024 at 12:40 PM Adrian Klaver 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?
Re: 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). 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.kla...@aklaver.com
Re: 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 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. 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.kla...@aklaver.com
Mimic ALIAS in Postgresql?
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;
