| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-25 02:07:33 |
| Message-ID: | 20200625020733.GF130132@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 24, 2020 at 12:55:22PM -0400, Tom Lane wrote:
> 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.
0d8c9c1 has introduced some in parse_basebackup_options() for the
new manifest option, and fe30e7e for AlterType(), no?
> 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.
Yep, there were a couple of exceptions. What was done at this time
was a case-by-case lookup to check what came only from the parser.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-06-25 02:16:04 | Re: Assertion failure in pg_copy_logical_replication_slot() |
| Previous Message | David Rowley | 2020-06-25 01:50:37 | Keep elog(ERROR) and ereport(ERROR) calls in the cold path |