Fix violations of CatalogTupleInsert/Update/Delete abstraction.

In commits 2f5c9d9c9 and ab0289651 we invented an abstraction layer
to insulate catalog manipulations from direct heap update calls.
But evidently some patches that hadn't landed in-tree at that point
didn't get the memo completely.  Fix a couple of direct calls to
simple_heap_delete to use CatalogTupleDelete instead; these appear
to have been added in commits 7c4f52409 and 7b504eb28.  This change is
purely cosmetic ATM, but there's no point in having an abstraction layer
if we allow random code to break it.

Masahiko Sawada and Tom Lane

Discussion: https://postgr.es/m/CAD21AoDOPRSVcwbnCN3Y1n_68ATyTspsU6=ygtHz_uY0VcdZ8A@mail.gmail.com
This commit is contained in:
Tom Lane 2017-06-14 10:26:46 -04:00
parent d3c3f2b1e2
commit a571c7f661
2 changed files with 3 additions and 4 deletions

View File

@ -401,7 +401,7 @@ RemoveSubscriptionRel(Oid subid, Oid relid)
scan = heap_beginscan_catalog(rel, nkeys, skey);
while (HeapTupleIsValid(tup = heap_getnext(scan, ForwardScanDirection)))
{
simple_heap_delete(rel, &tup->t_self);
CatalogTupleDelete(rel, &tup->t_self);
}
heap_endscan(scan);

View File

@ -301,8 +301,7 @@ CreateStatistics(CreateStatsStmt *stmt)
/* insert it into pg_statistic_ext */
statrel = heap_open(StatisticExtRelationId, RowExclusiveLock);
htup = heap_form_tuple(statrel->rd_att, values, nulls);
CatalogTupleInsert(statrel, htup);
statoid = HeapTupleGetOid(htup);
statoid = CatalogTupleInsert(statrel, htup);
heap_freetuple(htup);
relation_close(statrel, RowExclusiveLock);
@ -372,7 +371,7 @@ RemoveStatisticsById(Oid statsOid)
CacheInvalidateRelcacheByRelid(relid);
simple_heap_delete(relation, &tup->t_self);
CatalogTupleDelete(relation, &tup->t_self);
ReleaseSysCache(tup);