On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote:
> use. The people that need them understand the ramifications of row
> filtering and the absence of inaccessible rows won't be surprising.
I wish there was even a little bit of evidence that users of a
security system may be relied upon to understand its implications and
effects. In my experience, however, they often don't.
>> you have to have them seems fairly weak, certainly not strong enough to
>> justify the costs. We have already touched on some ways that you can
>
> The costs are nil for people who don't want this feature.
That's also false, because developers who don't care about the feature
have to continue to maintain it as part of the system. If maintenance
were free, I suspect nobody would be objecting to the feature. But
this feature will in fact constrain future development and will impose
maintenance requirements on the programmers of the system. Those
maintenance requirements in turn amount to a cost that every user has
to pay, because time spent addressing issues that result from this
feature (or accommodating it in new development) is time that is not
spent on other problems users might face.
If I imagined I were project manager of the PostgreSQL project (a
preposterous supposition, let me be clear), then I'd be very worried
that this feature, which is apparently poorly understood by at least
one big contributor to the project, would amount to a significant drag
on future development work. In that case, I'd have to ask why having
this feature as part of the main line of PostgreSQL is a good
trade-off. Happily, I'm not someone who has to make that
determination, so I can't say whether it _is_ a good trade-off. But I
think that's what the resistance to the feature is all about, so
you'll need to make the case that the trade-off is a good one.
A
--
Andrew Sullivan
ajs@crankycanuck.ca