Re: ALTER TABLE SET (toast.asdf) is not rejected ... if a table has no toast

On Mon, Jun 11, 2018 at 11:47:59AM -0400, Alvaro Herrera wrote:
> On 2018-Jun-11, Justin Pryzby wrote:
>
> > I noticed that this is accepted:
> >
> > postgres=# ALTER TABLE t SET (toast.asdf=128);
> > ALTER TABLE
> >
> > I thought since "toast" was a core namespace, it would've been rejected?
> >
> > I recall having read a discussion about verifying these ... I wasn't able
> > to find what I was thinking of, but found this one.
> > https://www.postgresql.org/message-id/flat/20090114144332.GF24156%40alvh.no-ip.org

>
> Uh. ISTM that this was lost during the 9.4 cycle, because that command *is*
> rejected in 9.3.
> alvherre=# ALTER TABLE t SET (toast.asdf=128);
> ERROR: unrecognized parameter "asdf"

I'm assuming your "t" has a toast table. I think this is properly rejected
when toast exists.

It looks like we were maybe both (partially?) fooled by behavior that's been
discussed multiple times over the years: SET (toast.*) is ignored for tables
which don't currently have any TOAST.
https://www.postgresql.org/message-id/flat/20090211194311.GP8924%40alvh.no-ip.org

Maybe all's well, but I suggest there's maybe an question which hasn't been
previously been disambiguated and raised: if a table has no toast, should SET
(toast.JUNK) be ignored, or rejected ?

BTW maybe I was originally thinking of this:
https://www.postgresql.org/message-id/flat/c4d71df2-9e0e-3912-dc81-9a72e080c238%40lab(dot)ntt(dot)co(dot)jp#c4d71df2-9e0e-3912-dc81-9a72e080c238(at)lab(dot)ntt(dot)co(dot)jp

Justin