Re: createdb compares strategy as case-sensitive - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: createdb compares strategy as case-sensitive
Date
Msg-id 86ed7de6-2f04-4c38-ae82-7927da98e38e@enterprisedb.com
Whole thread Raw
In response to Re: createdb compares strategy as case-sensitive  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: createdb compares strategy as case-sensitive
List pgsql-hackers

On 4/20/24 22:40, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> While doing some testing with createdb, I noticed it only accepts
>> file_copy/wal_log as valid strategies, not FILE_COPY/WAL_LOG (which is
>> what the docs say). The same thing applies to CREATE DATABASE.
> 
> Hmm, actually it does work in CREATE DATABASE:
> 
> regression=# create database foo STRATEGY = FILE_COPY;
> CREATE DATABASE
> 
> but it fails in createdb because that does
> 
>     if (strategy)
>         appendPQExpBuffer(&sql, " STRATEGY %s", fmtId(strategy));
> 
> and fmtId will double-quote the strategy if it's upper-case, and then
> the backend grammar doesn't case-fold it, and kaboom.
> 

Oh, right. I should have tested CREATE DATABASE instead of just assuming
it has the same issue ...

>> The problem is that createdb() does the check using strcmp() which is
>> case-sensitive. IMHO this should do pg_strcasecmp() which is what we do
>> for other string parameters nearby.
> 
> Seems reasonable.  The alternative could be to remove createdb.c's use
> of fmtId() here, but I don't think that's actually better.
> 

Why? It seems to me this is quite close to e.g. LOCALE_PROVIDER, and we
don't do fmtId() for that. So why should we do that for STRATEGY?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: createdb compares strategy as case-sensitive
Next
From: Tom Lane
Date:
Subject: Re: createdb compares strategy as case-sensitive