Re: Extending USING [heap | mytam | yourtam] grammar and behavior

On Wed, Jun 15, 2022 at 8:51 PM Michael Paquier <michael(at)paquier(dot)xyz> 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 depends on a GUC in this manner. The fact that
it is user-settable is, IMO, a flaw, not a feature, at least as far as
production settings are concerned.

It is a novel API for PostgreSQL to rely upon setting a GUC then attaching
"unless" configurations to individual objects to ignore it. And what would
be chosen (ultimately fallback is heap?), or whether it would simply error,
is presently, as you say, undefined.

In production this general behavior becomes useful only under the condition
that among the various named access methods some of them don't even exist
on the server in question, but that a fallback option would be acceptable
in that case. But that suggests extending "USING" to accept
multiple names, not inventing a "NOT USING".

That all said, I can understand that testing presents its own special
needs. But testing is probably where GUCs shine. So why not implement
this capability as a GUC that is set just before the table is created
instead of extending the grammar for it? Add it to "developer options" and
call it a day. Dump/Restore no longer has to care about it, and its value
once the table exists is basically zero anyway.

David J.