Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Michael Banck wrote:
>> The other set of users I could think of are those who, for whatever
>> reason, tend to always compile PostgreSQL from source for their
>> company/organization. Maybe they have internal rules that requires a
>> custom installation prefix for all their servers or whatever. Due to
>> procedural requirements, or just the unwillingness to carry deltas, they
>> absolutely want to use the pristine tarballs as well but would be very
>> happy to get rid of some of the authentication methods.
> Right. That's the set of users that Josh B says is only comprised of
> Volker (the OP).
That might be a bit harsh, but here's the thing: assuming you're willing
to build from source, what is the reason for wanting $small_market_feature
to be built into Postgres rather than being something you carry a patch
for? ISTM the core reason is that you're expecting the community to carry
the load of testing and maintaining the feature. And the fact of the
matter is that we're not terribly good at testing non-mainstream build
options. (There is depressingly little variety in the configure options
used in the buildfarm, for example.) So I wouldn't be a bit surprised
if something like this broke every time somebody touched the auth code,
and we would not notice. It would only be reliable if it were something
the community tended to use regularly ... which gets us back to the point
that what needs to happen first is a credible replacement for "trust"
mode.
I think Andres' point about "trust" being an essential disaster recovery
mode is something to consider, as well. That puts pretty strict limits
on what would be a credible replacement.
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
