Re: Status of the table access method work - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Status of the table access method work
Date
Msg-id CA+q6zcXjrvhDdwx9rCGJmvQUz8AvBiS3ve+pxjj=EaDsZh5ttQ@mail.gmail.com
Whole thread Raw
In response to Re: Status of the table access method work  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Status of the table access method work
List pgsql-hackers
> On Fri, Apr 5, 2019 at 10:25 PM Andres Freund <andres@anarazel.de> wrote:
>
> A second set of limitations is around making more of tableam
> optional. Right now it e.g. is not possible to have an AM that doesn't
> implement insert/update/delete. Obviously an AM can just throw an error
> in the relevant callbacks, but I think it'd be better if we made those
> callbacks optional, and threw errors at parse-analysis time (both to
> make the errors consistent, and to ensure it's consistently thrown,
> rather than only when e.g. an UPDATE actually finds a row to update).

Agree, but I guess some of tableam still should be mandatory, and then I wonder
where to put the live between those that are optional and those that are not.
E.g. looks like it can be relatively straightforward (ignoring `create table as`
and some other stuff) to make insert/update/delete optional with messages at
analysis time, but for others like parallel scan related it's probably not.

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: New vacuum option to do only freezing
Next
From: Fabien COELHO
Date:
Subject: Re: [patch] pg_test_timing does not prompt illegal option