The example here
http://archives.postgresql.org/pgsql-novice/2008-06/msg00025.php
shows that we are failing to regenerate cached plans when a table
referenced by a regclass constant is removed. This is pretty minor
in the big scheme of things, but it's still annoying since there is
code in there that's explicitly intended to make that work (see
fix_scan_expr in setrefs.c). I looked into why not, and soon
realized that the example case really is 'tablename'::regclass::oid
(ie, a RelabelType node atop a Const) because the constant is an
argument to oideq(). So constant folding reduces that to just a
Const of type OID, and fix_scan_expr doesn't think it's interesting.
I see two ways this might be fixed:
1. Don't constant-fold this particular case. Costs: very ugly
special case in constant folding, and a tiny execution-time penalty.
2. Make fix_scan_expr treat Consts of type OID like regclass Consts.
Costs: some bogus additions to the list of relation OIDs a plan
depends on, which would occasionally result in unnecessary replans.
Anyone have a preference, or see a third way? I'm kind of leaning
to #1, but it sure is ugly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
