Re: WIP: Rework access method interface
От | Alexander Korotkov |
---|---|
Тема | Re: WIP: Rework access method interface |
Дата | |
Msg-id | CAPpHfdt9AKqMRNDQ0m1+kMsDH44fmjEhwE5mAWBMwPP7D+dHEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Rework access method interface (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Rework access method interface
|
Список | pgsql-hackers |
On Tue, Aug 25, 2015 at 7:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> On 8/25/15 10:56 AM, Tom Lane wrote:
>> I'm good with this as long as all the things that get stored in pg_am
>> are things that pg_class.relam can legitimately reference. If somebody
>> proposed adding an "access method" kind that was not a relation access
>> method, I'd probably push back on whether that should be in pg_am or
>> someplace else.
> Would fields in pg_am be overloaded then?
No, because the proposal was to reduce pg_am to just amname, amkind
(which would be something like 'i' or 's'), and amhandler. Everything
specific to a particular type of access method would be shoved down to
the level of the C APIs.
OK. So, as we mentioned before, if we need to expose something of am parameters at SQL-level then we need to write special functions which would call amhandler and expose it.
Did we come to the agreement on this solution?
> From a SQL standpoint it'd be
> much nicer to have child tables, though that could potentially be faked
> with views.
I've looked into having actual child tables in the system catalogs, and
I'm afraid that the pain-to-reward ratio doesn't look very good.
Agree. Teach syscache about inheritance would be overengeneering for this problem.
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: