> That leaves the question of whether it's worth detecting table-level
> option changes this way, or whether we should just handle those by forcing
> a relcache inval in ATExecGenericOptions, as in Amit's original patch in
> <5702298d.4090...@lab.ntt.co.jp>.  I kind of like that approach; that
> patch was short and sweet, and it put the cost on the unusual path (ALTER
> TABLE) not the common path (every time we create a query plan).

You seemed not sure about this solution per [1]. Do you think we
should add similar cache invalidation when foreign server and FDW
options are modified?

> That leaves not much of this patch :-( though maybe we could salvage some
> of the test cases.

If that's the best way, we can add testcases to that patch.

[1] https://www.postgresql.org/message-id/29681.1459779...@sss.pgh.pa.us

Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to