From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] COPY command's data format option allows only lowercase csv, text or binary |
Date: | 2020-06-24 16:55:22 |
Message-ID: | 2213223.1593017722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 24, 2020 at 10:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> More generally, though, why would we want to change this policy only
>> here? I believe we're reasonably consistent about letting the parser
>> do any required down-casing and then just checking keyword matches
>> with strcmp.
> ... Mind you, I'm not sure whether or not anything really needs to be
> changed, or exactly what ought to be done. I'm just making the
> observation that it might not be as consistent as you may think.
Yeah, I'm sure there are a few inconsistencies. We previously made a
pass to get rid of pg_strcasecmp for anything that had been through
the parser's downcasing (commit fb8697b31) but I wouldn't be surprised
if that missed a few cases, or if new ones have snuck in. Anyway,
"don't use pg_strcasecmp unnecessarily" was definitely the agreed-to
policy as of Jan 2018.
My vague recollection is that there are a few exceptions (defGetBoolean
may well be one of them) where pg_strcasecmp still seemed necessary
because the input might not have come through the parser in some usages.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-06-24 17:05:49 | Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 |
Previous Message | Stephen Frost | 2020-06-24 16:53:28 | Re: PostgreSQL and big data - FDW |