From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: No longer possible to query catalogs for index capabilities? |
Date: | 2016-08-11 15:35:24 |
Message-ID: | 12903.1470929724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Aug 10, 2016 at 6:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-08-11 15:45:19 | Re: [Patch] New psql prompt substitution %r (m = master, r = replica) |
Previous Message | Peter Eisentraut | 2016-08-11 15:32:21 | Re: improved DefElem list processing |