Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In short, I do not see a good reason to expose ampredlocks at the SQL
>> level, and I think there needs to be a darn good reason to expose any of
>> this stuff, not just "maybe some DBA will think he needs to query this".
> I don't think you're being unreasonable, but I don't agree with your
> approach. I think that we should expose everything we reasonably can,
> and if we have to change it later then it will be a backward
> compatibility break. Making it unqueryable in the hopes that people
> won't try to query it is futile.
Well, if it's unqueryable they won't be able to query it no matter how
hard they try ;-). But my point here is that up to now, we never had the
opportunity to draw a line between user-visible and non-user-visible AM
properties; if it needed to be in pg_am, that's where it went. Now that
we do have an opportunity, we should draw the line in an intelligent
fashion, not blindly assume that everything that was in pg_am should
remain exposed. I think that neither amoptionalkey nor ampredlocks is
of real use to applications, and there are easily foreseeable reasons
why they would disappear or change behavior substantially. So I feel
we should leave them out of the API.
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
