On 2014-03-13 09:17:36 -0400, Robert Haas wrote:
> It is very true that there are other ways for extensions to manage
> per-table options.
You previously said that, but I really don't see any. Which way out
there exists that a) doesn't leave garbage after the relation is dropped
or renamed b) is properly dumped by pg_dump c) is properly integratable
with cache invalidations.
c) is hackable by manually sending cache invalidations from C code when
changing the associated information, and by using a relcache callback
for cache invalidation, but the others really aren't solveable right now
afaics.
> The bottom line here is that, as in previous years, there are a
> certain number of people who show up near the end of CF4 and are
> unhappy that some patch didn't get committed. Generally, they allege
> that (1) there's nothing wrong with the patch, (2) if there is
> something wrong with the patch, then it's the fault of the people
> objecting for not volunteering to fix it, and (3) that if the patch
> isn't committed despite the objections raised, it's going to be
> hideously bad for PostgreSQL.
I agree that this happens occasionally, but I don't really see evidence
of it in this case. We seem to be discussing the merit of the patch
itself, not the scheduling of a eventual commit.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services