Robert Haas <robertmh...@gmail.com> writes:
> I am as conservative about back-patching as anybody here, but
> debugging on Windows is not an easy thing to do, and I strongly
> suspect we are going to point people experiencing crashes on Windows
> to this code whether it's part of our official distribution or not.  I
> don't see what we get out of insisting that people install it
> separately.  This is a tool that is only intended to be used when
> PostgreSQL is CRASHING, so arguing that we shouldn't include the code
> because it might not be stable doesn't carry much water AFAICS.  As
> far as I understand it, we don't back-patch new features because of
> the risk of breaking things, but in this case refusing to back-patch
> the code seems more likely to prevent adequate diagnosis of what is
> already broken.

Well, if we're going to hand out prebuilt DLLs to people, we can do that
without having back-patched the code officially.  But more to the point
is that it's not clear that we're going to end up with a contrib module
at all going forward (a core feature would clearly be a lot more
reliable), and I really do not wish to get involved with maintaining two
independent versions of this code.

This argument seems to boil down to "we have to have this yesterday",
which I don't buy for a minute.  If it's as critical as that, why did
it take this long for someone to write it?  I do NOT agree that this
feature is important enough to justify a free pass around our normal
management and quality assurance processes.

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to