On Tuesday, January 31, 2023 10:49 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
Hi, > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Tue, Jan 31, 2023 at 4:25 AM Tom Lane <t...@sss.pgh.pa.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. I understand the worry of parsing oddities. I think we have tried to make the streaming option keep accepting all the same spellings of boolean(e.g. the option still accept(1/0/true/false...)). And this is similar to some other option like COPY HEADER option which accepts all the boolean value and the 'match' value. Some other GUCs like wal_compression also behave similarly: 0/1/true/false/on/off/lz1/pglz are all valid values. Best Regards, Hou zj
