On 4/21/24 17:10, Tom Lane wrote:
> Tomas Vondra 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
Tomas Vondra 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
On 4/21/24 00:19, Tom Lane wrote:
> Tomas Vondra writes:
>> On 4/20/24 22:40, Tom Lane wrote:
>>> 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.
Tomas Vondra writes:
> On 4/20/24 22:40, Tom Lane wrote:
>> 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.
On 4/20/24 22:40, Tom Lane wrote:
> Tomas Vondra 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
Tomas Vondra 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
