| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | LEMAIRE Leslie (Chargée de mission) - SG/DNUM/UNI/DRC <leslie(dot)lemaire(at)developpement-durable(dot)gouv(dot)fr> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Cast to regrole on a literal string in a PL/pgSQL function |
| Date: | 2025-09-30 15:29:51 |
| Message-ID: | 491035.1759246191@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
=?UTF-8?Q?LEMAIRE_Leslie_=28Charg=C3=A9e_de_mission=29_=2D_SG=2FDNUM=2F?= =?UTF-8?Q?UNI=2FDRC?= <leslie(dot)lemaire(at)developpement-durable(dot)gouv(dot)fr> writes:
> I'm surprised that regnamespace isn't handled properly either, by the
> way. One test can't prove much, but this one doesn't fail with a cast to
> regnamespace, unlike all other reg* except regclass.
regnamespace constants do work, accidentally, because plancache.c
is set up to flush *all* cached plans after any change in
pg_namespace. That's because the possible effects on search-path
lookups are too hard to predict.
Now that I look, regoper/regoperator constants would probably be okay
too, because changes in pg_operator also cause a plancache flush.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-10-01 05:24:52 | Re: Potential bug: Enforcing/not enforcing a CHECK constraint fails on an empty table |
| Previous Message | Erki Eessaar | 2025-09-30 12:12:15 | Re: Potential bug: Enforcing/not enforcing a CHECK constraint fails on an empty table |