Re: postgres_fdw - should we tighten up batch_size, fetch_size options against non-numeric values?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-18T13:49:22Z
Lists: pgsql-hackers
Fujii Masao <masao.fujii@oss.nttdata.com> writes: > On 2021/05/17 18:58, Bharath Rupireddy wrote: >> It looks like the values such as '123.456', '789.123' '100$%$#$#', >> '9,223,372,' are accepted and treated as valid integers for >> postgres_fdw options batch_size and fetch_size. Whereas this is not >> the case with fdw_startup_cost and fdw_tuple_cost options for which an >> error is thrown. Attaching a patch to fix that. > This looks an improvement. But one issue is that the restore of > dump file taken by pg_dump from v13 may fail for v14 with this patch > if it contains invalid setting of fetch_size, e.g., "fetch_size '123.456'". > OTOH, since batch_size was added in v14, it has no such issue. Maybe better to just silently round to integer? I think that's what we generally do with integer GUCs these days, eg regression=# set work_mem = 102.9; SET regression=# show work_mem; work_mem ---------- 103kB (1 row) I agree with throwing an error for non-numeric junk though. Allowing that on the grounds of backwards compatibility seems like too much of a stretch. regards, tom lane
Commits
-
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
- 4173477b3841 14.0 landed
- d854720df6df 15.0 landed
-
doc: Add type information for postgres_fdw parameters.
- 61d599ede742 15.0 cited