Robert Haas wrote:
> The transforms patch seems to have forgotten to add
> TransformRelationId to object_classes[], much like the RLS patch
> forgot to add PolicyRelationId in the same place.
>
> Fixing this is easy, but ISTM that we need to insert some sort of a
> guard to prevent people from continuing to forget this, because it's
> apparently quite easy to do. Perhaps add_object_address should
> Assert(OidIsValid(object_classes[oclass])),
The problem is that there aren't enough callers of add_object_address:
there are many indexes of that array that aren't ever accessed and so
it's not obvious when the array is broken. If we were to put
OCLASS_CLASS at the end instead of at the beginning, that would fix the
problem by making it immediately obvious when things get broken this
way, because the value used in the most common case would shift around
every time we add another value. (Of course, we'd have to instruct
people to not add new members after the pg_class entry.)
I just tried this, and it's a bit nasty: while it does causes the tests
to fail, it's not at all obvious that there's a connection between the
failure and object_classes[]. I think we can solve that by adding a
comment to ObjectClass. Here's the first hunk in the large regression
failure:
*** /pgsql/source/master/src/test/regress/expected/triggers.out 2015-05-22 20:09:28.936186873 +0200
--- /home/alvherre/Code/pgsql/build/master/src/test/regress/results/triggers.out 2015-07-18 17:26:13.
664764070 +0200
***************
*** 1429,1437 ****
(4 rows)
DROP TABLE city_table CASCADE;
- NOTICE: drop cascades to 2 other objects
- DETAIL: drop cascades to view city_view
- drop cascades to view european_city_view
DROP TABLE country_table;
-- Test pg_trigger_depth()
create table depth_a (id int not null primary key);
--- 1429,1434 ----
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
