Simon Riggs wrote:
On Fri, 2009-05-15 at 10:17 -0400, Andrew Dunstan wrote:
This whole area is unfortunately way too fragile. We need some way of
managing these facilities that hides a lot of these details and is
therefore less likely to produce shot feet, IMNSHO. I get very nervous
every time I have to touch it.
I think it is complex, though that is because we now support a huge
number of use cases and options, to the benefit of many users. In fact,
more than I would like, but this is a group project.
Not sure why you say it's fragile; there have been very few bugs
considering the wide user base and those that have occurred have had
fixes submitted for them quickly. Yes, we require you to actually read
the docs, rather than open up psql and play, but this is business
critical stuff.
Realistically, we have more developers on this part of the code now than
any other. That's one reason for all the debate.
No problem in receiving feedback, just want to be able to understand it
sufficiently well to be able to enhance it.
I don't mean that it has bugs. I mean that it's far too easy to get it
wrong and far too hard to get it right. I have reduced my uses to a
couple of cases where I have worked out, with some trial and error,
recipes that I follow. If I find these facilities complex to use, and I
make virtually 100% of my living working with Postgres, what are more
ordinary users going to say? That's why I think we need at the very
least some tools for supporting the most common use cases, and hiding
the messy details.
And no, I haven't even begun to think of what such tools might look like.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
