Re: [PATCH] COPY command's data format option allows only lowercase csv, text or binary
От | Tom Lane |
---|---|
Тема | Re: [PATCH] COPY command's data format option allows only lowercase csv, text or binary |
Дата | |
Msg-id | 2213223.1593017722@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] COPY command's data format option allows only lowercasecsv, text or binary (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] COPY command's data format option allows only lowercasecsv, text or binary
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jun 24, 2020 at 10:27 AM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: