Robert Haas wrote > That's a sufficiently astonishing result that it wouldn't be > surprising for this to get reported as a bug where a simple > performance gap wouldn't be, and I think if we don't fix it the > perception will be that we've left that bug unfixed. Now, there are > lots of things we don't fix just because there is not an infinitely > large army of trained PostgreSQL hackers who love to fix other > people's bugs for free, so I'm not going to say we HAVE to fix this or > whatever - but neither do I think fixing it is useless and worthless.
Having had this same thought WRT the "FOR UPDATE in LOOP" bug posting the lack of a listing of outstanding bugs does leave some gaps. I would imagine people would appreciate something like: Frequency: Rare Severity: Low Fix Complexity: Moderate Work Around: Easy - create an actual function; create some form of loop Status: Confirmed - Awaiting Volunteers to Fix Even without a formal system it may not hurt for bug threads to have a posting with this kind of information summarizing the thread. As Tom is apt to do - "for the sake of the archives" - though mostly I see those once something has been fixed and not for items that are being left open. Ideally these could also be migrated to the wiki, with links back to the main thread, to provide a basic "known open items" interface - something that I imagine would make corporate acceptance of PostgreSQL more likely. I don't see where there are a considerably large number of these unresolved items - most things do indeed get fixed or explained away as normal user learning. Sorry for the digression but it seems relevant. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Transaction-lifespan-memory-leak-with-plpgsql-DO-blocks-tp5777942p5778001.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers