> On Jun 15, 2022, at 8:51 PM, Michael Paquier wrote:
>
> I am not sure to see why this would be something users would actually
> use in prod. That means to pick up something else than what the
> server thinks is the best default AM but where somebody does not want
> to trust the default,
> On Jun 15, 2022, at 8:51 PM, Michael Paquier wrote:
>
> However,
> your problem is basically that you develop multiple AMs, but you want
> to have regression tests that do checks across more than one table AM
> at the same time.
It is true that I test multiple table AMs at the same time,
On Wed, Jun 15, 2022 at 8:51 PM Michael Paquier wrote:
> On top of that
> default_table_access_method is user-settable.
>
>
FWIW this proposal acknowledges that and basically leverages it to the
hilt, turning it into something like search_path. I strongly dislike the
idea of any workflow that
On Wed, Jun 15, 2022 at 06:16:21PM -0700, Mark Dilger wrote:
> When developing two or more TAMs, this falls apart. Some tests may
> be worth fixing up (perhaps with alternate output files) for
> "mytam", but not for "columnar_tam". That might be because the test
> is checking fundamentally
Hackers,
I have extended the grammar to allow "USING NOT method [, ...]" to exclude one
or more TAMs in a CREATE TABLE statement. This may sound like a weird thing to
do, but it is surprisingly useful when developing new Table Access Methods,
particularly when you are developing two or more,
