Here is what I have staged for commit.
--
nathan
>From 41168622a142ae40e43f9d71b8ed1e992fe4e4a2 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 24 Jun 2025 14:57:31 -0500
Subject: [PATCH v7 1/1] Add new OID alias type regdatabase.
MIME-Version: 1.0
Content-Type: text/plain; charset=
>> even after reading lots of threads, code, and docs, I'm still not sure I
>> fully grasp all the details here.
>
> It's all quite squishy, unfortunately, because shippability is a
> heuristic rather than something we can determine with certainty
> (at reasonable
> fully grasp all the details here.
It's all quite squishy, unfortunately, because shippability is a
heuristic rather than something we can determine with certainty
(at reasonable cost, anyway). But I agree with treating regdatabase
the same as the other reg* types,
ly grasp all the details here.
>
> [0] https://postgr.es/m/flat/1423433.1652722406%40sss.pgh.pa.us
>
I agree with blocking it for now. The patch LGTM, all tests pass and seems
to cover all the changes.
Not sure if it is worth having some dump/restore tap tests for tables with
regdatabase type.
Regards,
--
Fabrízio de Royes Mello
r shipping reg* values in the first place. But
even after reading lots of threads, code, and docs, I'm still not sure I
fully grasp all the details here.
[0] https://postgr.es/m/flat/1423433.1652722406%40sss.pgh.pa.us
--
nathan
>From 54bf1375622791212e3fde8a823b2107df66b8a9 Mon Sep 1
On Mon, May 19, 2025 at 10:37:29AM +0800, jian he wrote:
> I saw REGROLEOID in foreign_expr_walker,
> I'm wondering whether REGDATABASEOID is reachable within foreign_expr_walker.
>
> not familiar with this area, also there are no coverage tests for
> other reg*Const,
> per
> https://coverage.pos
On Thu, May 8, 2025 at 11:20 PM Nathan Bossart wrote:
>
> On Thu, May 08, 2025 at 10:38:04PM +0900, Ian Lawrence Barwick wrote:
> > Revised patch attached which adds coverage of that and also for the
> > "constant of the type reg(role|database) cannot be used here" error.
>
> LGTM. I've marked it
On Thu, May 08, 2025 at 10:38:04PM +0900, Ian Lawrence Barwick wrote:
> Revised patch attached which adds coverage of that and also for the
> "constant of the type reg(role|database) cannot be used here" error.
LGTM. I've marked it as ready-for-committer [0] and will plan on
committing it as soon
>> had a chance to look at the code beyond fixing it, however.
>
> I spent some time on this one. I saw two main things:
>
> * As of commit aa01051, pg_upgrade does preserve database OIDs, so we don't
> need to block for tables with columns of type regdatabase.
>
>
:00:00 2001
From: Nathan Bossart
Date: Wed, 7 May 2025 22:24:31 -0500
Subject: [PATCH v4 1/1] Add regdatabase.
XXX: NEEDS CATVERSION BUMP
Author: Ian Lawrence Barwick
Reviewed-by: Greg Sabino Mullane
Discussion: https://postgr.es/m/aBpjJhyHpM2LYcG0%40nathan
---
doc/src/sgml/da
.
I spent some time on this one. I saw two main things:
* As of commit aa01051, pg_upgrade does preserve database OIDs, so we don't
need to block for tables with columns of type regdatabase.
* Some of the regproc.c code needs to use the soft error functions instead.
I believe both of the
ce patch, very thorough; applies cleanly; all tests pass;
acts as I would expect when testing manually.
Minor pgindent issue in the comment in src/backend/catalog/dependency.c
Would be nice to have test coverage of our special "single dash" case, e.g.
select regdatabase('-')::oid
On Tue, 6 May 2025 at 21:29, Nathan Bossart wrote:
>
> Every once in a while, I find myself wanting to use regdatabase for
> something like current_database()::regdatabase, and I'm always surprised
> when I inevitably rediscover that it doesn't exist.
+1 for the idea. I
c/src/sgml/datatype.sgml
index 09309ba0390..cab8f0fda93 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -4737,6 +4737,10 @@ INSERT INTO mytable VALUES(-1); -- fails
regconfig
+
+regdatabase
+
+
regdictionary
@@ -4878,6 +4882,13 @@ SEL
Nathan Bossart writes:
> * Would anyone object if I put together some patches to add regdatabase?
The original concept of the reg* types was to implement lookups for
cases that are more complicated than "(SELECT oid FROM pg_foo WHERE
fooname = 'whatever')". As an example
On Wed, May 07, 2025 at 08:45:15AM +0900, Michael Paquier wrote:
> For regdatabase, there would be at least two simplications related to
> the dump of subscriptions, where we could switch the queries to the
> new grammar for backend versions able to support the new grammar,
> meaning t
On Wed, May 07, 2025 at 09:18:28AM +0900, Ian Lawrence Barwick wrote:
> Hah, I put together a patch to implement just that a while back, but
> then concluded
> for some reason that it would likely be rejected so saved myself the
> humiliation of
> submitting it...
>
> Attaching patch for reference
2025年5月7日(水) 4:29 Nathan Bossart :
>
> Every once in a while, I find myself wanting to use regdatabase for
> something like current_database()::regdatabase, and I'm always surprised
> when I inevitably rediscover that it doesn't exist. I only found one
> reference to th
On Wed, May 07, 2025 at 07:28:02AM +0900, Tatsuo Ishii wrote:
> I think regdatabase is a good idea.
I've also found your reference from the lists of 2019 to be the only
one referring to a regdatabase.
If it means that I will type less by not having to do joins with
pg_database, count me
> Every once in a while, I find myself wanting to use regdatabase for
> something like current_database()::regdatabase, and I'm always surprised
> when I inevitably rediscover that it doesn't exist. I only found one
> reference to the idea in the archives [0]. So, I have tw
Every once in a while, I find myself wanting to use regdatabase for
something like current_database()::regdatabase, and I'm always surprised
when I inevitably rediscover that it doesn't exist. I only found one
reference to the idea in the archives [0]. So, I have two questions:
* I
21 matches
Mail list logo
