From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: createdb compares strategy as case-sensitive |
Date: | 2024-04-21 15:10:12 |
Message-ID: | 2724418.1713712212@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> On 4/21/24 00:19, Tom Lane wrote:
>> I'm not suggesting that this is an interesting security vulnerability,
>> because if you can control the arguments to createdb it's probably
>> game over long since. But wrapping the arguments is good for
>> delivering on-point error messages. So I'd add a fmtId() call to
>> LOCALE_PROVIDER too.
> OK, the attached 0001 patch does these three things - adds the fmtId()
> for locale_provider, make the comparison case-insensitive for strategy
> and also removes the comma from the hint.
LGTM.
> The createdb vs. CREATE DATABASE difference made me look if we have any
> regression tests for CREATE DATABASE, and we don't. I guess it would be
> good to have some, so I added a couple, for some of the parameters, see
> 0002. But there's a problem with the locale stuff - this seems to work
> in plain "make check", but pg_upgrade creates the clusters with
> different providers etc. which changes the expected output. I'm not sure
> there's a good way to deal with this ...
Probably not worth the trouble, really.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-04-21 19:34:47 | Re: createdb compares strategy as case-sensitive |
Previous Message | Tomas Vondra | 2024-04-21 12:35:15 | Re: createdb compares strategy as case-sensitive |