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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Extending USING [heap | mytam | yourtam] grammar and behavior
Дата
Msg-id 59B69460-BEA2-4D96-92CB-527E6F5FFD2B@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Extending USING [heap | mytam | yourtam] grammar and behavior  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers

> On Jun 15, 2022, at 8:51 PM, Michael Paquier <michael@paquier.xyz> 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, while generating an error if specifying the
> default AM in the USING NOT clause.

Sorry for the lack of clarity.  I do not suggest raising an error.  If you say "USING NOT foo", and foo is the default
tableaccess method, then you get the same behavior as a "USING heap" would have gotten you, otherwise, you get the same
behavioras not providing any USING clause at all. 

In future, we might want to create a list of fallback tams rather than just hardcoding "heap" as the one and only
fallback,but I haven't run into an actual need for that.  If you're wondering what "USING NOT heap" falls back to, I
thinkthat could error, or it could just use heap anyway.  Whatever.  That's why I'm still soliciting for comments at
thisphase rather than posting a patch. 

>  On top of that
> default_table_access_method is user-settable.

Yeah, but specifying a "USING foo" clause is also open to any user, so I don't see why this matters.  "USING NOT foo"
isjust shorthand for checking the current default_table_access_method, and then either appending a "USING heap" clause
orappending no clause.  Since the user can do this anyway, what's the security implication in some syntactic sugar? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Lepikhov
Дата:
Сообщение: Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Replica Identity check of partition table on subscriber