> > 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: http://www.postgresql.org/mailpref/pgsql-hackers
