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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
