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

> 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.


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:

Reply via email to