Re: pub/sub - specifying optional parameters without values.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Zheng Li <zhengli10(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pub/sub - specifying optional parameters without values.
Date: 2023-01-31 14:49:03
Message-ID: 1075167.1675176543@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Tue, Jan 31, 2023 at 4:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hmph. I generally think that options defined like this (it's a boolean,
>> except it isn't) are a bad idea, and would prefer to see that API
>> rethought while we still can.

> We have discussed this during development and considered using a
> separate option like parallel = on (or say parallel_workers = n) but
> there were challenges with the same. See discussion in email [1]. We
> also checked that we have various other places using something similar
> for options. For example COPY commands option: HEADER [ boolean |
> MATCH ].

Yeah, and it's bad experiences with the existing cases that make me
not want to add more. Every one of those was somebody taking the
easy way out. It generally leads to parsing oddities, such as
not accepting all the same spellings of "boolean" as before.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2023-01-31 14:54:36 Re: Logical replication timeout problem
Previous Message Tom Lane 2023-01-31 14:45:56 Re: Assert fcinfo has enough args before allowing parameter access (was: Re: generate_series for timestamptz and time zone problem)