| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Subject: | Re: Allowing REINDEX to have an optional name |
| Date: | 2022-05-31 12:30:32 |
| Message-ID: | 202205311230.5dc4ztvncsck@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022-May-31, Michael Paquier wrote:
> The case with CONCURRENTLY is different though: the option will never
> work on system catalogs so we have to skip them. Echoing with others
> on this thread, I don't think that we should introduce a different
> behavior on what's basically the same grammar. That's just going to
> lead to more confusion. So REINDEX DATABASE with or without a
> database name appended to it should always mean to reindex the
> catalogs on top of the existing relations.
I was thinking the opposite: REINDEX DATABASE with or without a database
name should always process the user relations and skip system catalogs.
If the user wants to do both, then they can use REINDEX SYSTEM in
addition.
The reason for doing it like this is that there is no way to process
only user tables and skip catalogs. So this is better for
composability.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Most hackers will be perfectly comfortable conceptualizing users as entropy
sources, so let's move on." (Nathaniel Smith)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-05-31 12:35:23 | Re: doc: CREATE FOREIGN TABLE .. PARTITION OF .. DEFAULT |
| Previous Message | Robert Haas | 2022-05-31 12:20:53 | Re: "ERROR: latch already owned" on gharial |