Re: Collations and Replication; Next Steps

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Matthew Kelly <mkelly(at)tripadvisor(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Matthew Spilich <mspilich(at)tripadvisor(dot)com>
Subject: Re: Collations and Replication; Next Steps
Date: 2014-09-17 18:22:33
Message-ID: CAM3SWZQm-7F95rp30fFY=tMMy+NC96Z3FfN=yVHsabez_-TpSA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 17, 2014 at 11:08 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> I also wrote PostGIS dependent libraries, not PostGIS itself. If you
> are comparing RHEL 5 and 6, as you wrote elsewhere, then some of those
> will most likely be different. (Heck, glibc could be different. Is
> glibc never allowed to fix insufficiencies in its floating-point
> implementation, for example?)

The operator class author has a responsibility to make sure that
doesn't happen. If he or she should fail, then it's a bug, and
possibly a failure of imagination on their part. This is the only way
of thinking about it that makes sense. If you want to use a library
feature in your opclass B-Tree support function 1, then you'd better
be damned sure that it implies immutability insofar as that's
possible. Sure, it's also possible that your users could be the victim
on an unfortunate upstream bug that you couldn't reasonably predict,
but when is that not true?

In general, I am totally unconvinced by this line of argument. It
implies that everyone has to be an expert on everything just to use
Postgres.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-09-17 18:28:41 Re: [Windows,PATCH] Use faster, higher precision timer API
Previous Message Peter Eisentraut 2014-09-17 18:20:04 Re: Collations and Replication; Next Steps