From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should we replace the checks for access method OID with handler OID? |
Date: | 2020-08-27 15:50:56 |
Message-ID: | CA+TgmoZMREq8pJ+wHv73ZNHWD+vDy0Owpwbz8nDbfWKY-YHqSg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 27, 2020 at 5:37 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> While reviewing the patch for pg_surgery contrib module - [1], Asim
> Praveen suggested that it would be better to replace the check for
> access method OID with handler OID. Otherwise, if someone creates a
> new AM using the AM handler that is originally supported for e.g.
> "heap_tableam_handler" and if this new AM is used to create a table,
> then one cannot perform surgery on such tables because we have checks
> for access method OID which would reject this new AM as we only allow
> heap AM. For e.g. if we do this:
>
> create access method myam type table handler heap_tableam_handler;
> create table mytable (…) using myam;
>
> And use an access method OID check, we won't be able to perform
> surgery on mytable created above because it isn't the heap table
> although its table structure is actually heap.
The only reason I can see why it would make sense to do this sort of
thing is if you wanted to create a new AM for testing purposes which
behaves like some existing AM but is technically a different AM. And
if you did that, then I guess the change you are proposing would make
it behave more like it's the same thing after all, which seems like it
might be missing the point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2020-08-27 16:03:57 | Re: [PATCH] Covering SPGiST index |
Previous Message | Tom Lane | 2020-08-27 15:46:11 | Re: Clang Address Sanitizer (Postgres14) Detected Memory Leaks |