| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Shared access methods? |
| Date: | 2018-06-14 20:10:42 |
| Message-ID: | 9942.1529007042@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-06-14 15:59:22 +0300, Alexander Korotkov wrote:
>> We already have CREATE ACCESS METHOD command. I think this command
>> should handle that internally. And I don't understand why "ON
>> CONFLICT DO NOTHING". If AM with given name already exists in pg_am,
>> why should we ignore the error?
> Well, right now an AM containing extension creates things in each
> database (i.e. same scope as extensions). But with shared AMs that
> wouldn't be the case - you might still want to create the extension in
> another database. So we'd need to have CREATE ACCESS METHOD check
> whether already is the same entry, and only delete it on DROP ACCESS
> METHOD if there's no dependencies from other databases...
I'm not really buying this idea at all, at least not for index AMs,
because you also need a pile of other database-local infrastructure
--- opclasses, operators, functions, etc. Trying to make pieces of
that be shared is not going to end well.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bossart, Nathan | 2018-06-14 20:14:54 | Re: Microoptimization of Bitmapset usage in postgres_fdw |
| Previous Message | Alvaro Herrera | 2018-06-14 20:06:43 | Re: Possible bug in logical replication. |