| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Unqualified pg_catalog casts in pg_dump |
| Date: | 2020-03-23 16:54:04 |
| Message-ID: | 17869.1584982444@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> When looking at something different, I happened to notice that pg_dump is a bit
> inconsistent in how it qualifies casts to pg_catalog entities like regclass and
> oid. Most casts are qualified, but not all. Even though it functionally is
> the same, being consistent is a good thing IMO and I can't see a reason not to,
> so the attached patch adds qualifications (the unqualified regclass cast in the
> TAP test left on purpose).
While this used to be important before we made pg_dump force a minimal
search_path, I'm not sure that there's any point in being picky about
it anymore. (psql's describe.c is a different story though.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2020-03-23 16:57:37 | Re: Unqualified pg_catalog casts in pg_dump |
| Previous Message | Alvaro Herrera | 2020-03-23 16:50:59 | weird hash plan cost, starting with pg10 |