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
