| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Tracking role modification timestamps in pg_authid / pg_roles |
| Date: | 2026-08-27 05:07:22 |
| Message-ID: | 898256.1787807242@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com> writes:
> As promised, I have created an initial proof of concept that adds a
> last-updated timestamp to roles, databases, and tablespaces, labelled
> `rolupdated`, `datupdated`, and `spcupdated`, respectively.
I don't think that limiting this idea to global objects does one single
thing to address the problems with the concept, such as what are the
semantics for dump/restore. We've discussed modification timestamps
for database objects many times in the past, and rejected them every
single time. What exactly will be different this time?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2026-08-27 05:09:24 | Re: [PATCH] Release replication slot on error in SQL-callable slot functions |
| Previous Message | Henson Choi | 2026-08-27 04:57:48 | Re: Row pattern recognition |