Hello Noah,
07.07.2025 22:26, Noah Misch wrote:
A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and
"notnull_parent_upg nn" for the schema diff test that commit
172259afb563d35001410dc6daad78b250924038 added in v18:
@@ -436873,14 +436873,14 @@
ALTER TABLE public.insert
On Thu, Jul 24, 2025 at 10:27 PM Noah Misch wrote:
> I regret missing those in v1. I've attached v2, including branch-specific
> patches. I'll first need to back-patch 350e6b8, which fixed sorting of CREATE
> RULE, to v17 and earlier. Since 350e6b8 is conflict-free all the way back to
> v13, I'
On Mon, Jul 21, 2025 at 09:40:02AM -0400, Robert Haas wrote:
> On Fri, Jul 18, 2025 at 3:17 PM Noah Misch wrote:
> > +* Sort by encoding, per pg_collation_name_enc_nsp_index.
> > Wherever
> > +* this changes dump order, restoring the dump fails
> > anyway. CREAT
On Fri, Jul 18, 2025 at 3:17 PM Noah Misch wrote:
> > This comment is useful, but if I were to be critical, it does a better
> > job saying what this field isn't than what it is.
>
> True. I've changed it to this:
That looks great.
> - /* To have a stable sort order, break ties for some o
On Thu, Jul 17, 2025 at 09:24:02AM -0400, Robert Haas wrote:
> On Mon, Jul 7, 2025 at 3:27 PM Noah Misch wrote:
> > Let's get rid of pg_dump's need to sort by OID, apart from catalog
> > corruption
> > scenarios.
>
> +1. I had at one point believed that sorting by OID was a good way to
> make du
On Mon, Jul 7, 2025 at 3:27 PM Noah Misch wrote:
> Let's get rid of pg_dump's need to sort by OID, apart from catalog corruption
> scenarios.
+1. I had at one point believed that sorting by OID was a good way to
make dumps stable, but this disproves that theory. Sorting by logical
properties of t
A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and
"notnull_parent_upg nn" for the schema diff test that commit
172259afb563d35001410dc6daad78b250924038 added in v18:
@@ -436873,14 +436873,14 @@
ALTER TABLE public.insert_tbl
ADD CONSTRAINT ne_insert_tbl_con CHECK (((
