Addition of alias types regpublication and regsubscription

Started by vignesh Cover 5 years ago3 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

won't retrysuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44298
psql -h localhost -U postgres

Built from patchset v1 (message #1), July 27, 2026 at 04:57 PM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t44298_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t44298_1 && git checkout t44298_1

Patchset v1 (message #1) is on t44298_1

Jump to latest
#1vignesh C
vignesh21@gmail.com

Hi,

I felt inclusion of alias types regpublication and regsubscription will
help the logical replication users. This will also help in [1]/messages/by-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com.
The alias types allow simplified lookup of publication oid values for
objects. For example, to examine the pg_publication_rel rows, one could
write:
SELECT prpubid::regpublication, prrelid::regclass FROM pg_publication_rel;

rather than:
SELECT p.pubname, prrelid::regclass FROM pg_publication_rel pr,
pg_publication p WHERE pr.prpubid = p.oid;

Similarly in case of subscription:
For example, to examine the pg_subscription_rel rows, one could write:
SELECT srsubid::regsubscription, srrelid::regclass FROM pg_subscription_rel;

rather than:
SELECT s.subname,srsubid::regclass FROM pg_subscription_rel sr,
pg_subscription s where sr.srsubid = s.oid;

Attached patch has the changes for the same.
Thoughts?

[1]: /messages/by-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
/messages/by-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com

Regards,
Vignesh

Attachments:

t44298_1
v1-0001-Implement-type-regpublication.patchapplication/x-patch; name=v1-0001-Implement-type-regpublication.patchDownload+262-2
v1-0002-Implement-type-regsubscription.patchapplication/x-patch; name=v1-0002-Implement-type-regsubscription.patchDownload+256-2
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: vignesh C (#1)
Re: Addition of alias types regpublication and regsubscription

vignesh C <vignesh21@gmail.com> writes:

I felt inclusion of alias types regpublication and regsubscription will
help the logical replication users.

This doesn't really seem worth the trouble --- how often would you
use these?

If we had a policy of inventing reg* aliases for every kind of catalog
object, that'd be one thing, but we don't. (And the overhead in
inventing new object kinds is already high enough, so I'm not in favor
of creating such a policy.)

regards, tom lane

#3vignesh C
vignesh21@gmail.com
In reply to: Tom Lane (#2)
Re: Addition of alias types regpublication and regsubscription

On Sat, May 29, 2021 at 9:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

vignesh C <vignesh21@gmail.com> writes:

I felt inclusion of alias types regpublication and regsubscription will
help the logical replication users.

This doesn't really seem worth the trouble --- how often would you
use these?

If we had a policy of inventing reg* aliases for every kind of catalog
object, that'd be one thing, but we don't. (And the overhead in
inventing new object kinds is already high enough, so I'm not in favor
of creating such a policy.)

ok, Thanks for considering this.

Regards,
Vignesh