Re: regdatabase

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: regdatabase
Date: 2025-05-30 20:07:48
Message-ID: CAFcNs+qgf0rAy5DVh-niG-rd-NmrKJHLrm7aCpPFyGxBix18pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> >
> For now, I've just added another case block for REGDATABASEOID to match
the
> others. If there are problems with non-pinned objects being considered
> shippable, it's not really the fault of this patch. Also, from reading
> around [0], I get the idea that "shippability" might just mean that the
> same object _probably_ exists on the remote server. Plus, there seems to
> be very few use-cases for 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
>

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-05-30 20:19:41 Re: Large expressions in indexes can't be stored (non-TOASTable)
Previous Message Eduard Stefes 2025-05-30 19:41:04 RE: Review/Pull Request: Adding new CRC32C implementation for IBM S390X