Re: Buggy handling of redundant options in COPY

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Rémi Lapeyre <remi(dot)lapeyre(at)lenstra(dot)fr>
Subject: Re: Buggy handling of redundant options in COPY
Date: 2020-09-29 07:35:39
Message-ID: CAFj8pRA6kUxVcPOg-TD1iA_PXm7=R8CvaR_24q7=TKOzV0fmGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 29. 9. 2020 v 9:24 odesílatel Michael Paquier <michael(at)paquier(dot)xyz>
napsal:

> Hi all,
>
> While diving into the CF, I have noticed the following message from
> Remy (in CC):
>
> https://www.postgresql.org/message-id/0B55BD07-83E4-439F-AACC-FA2D7CF50532@lenstra.fr
>
> The following two cases should fail the same way, but the second does
> not because we check directly the flag value extracted from the
> DefElem to see if the option is repeated or not:
> =# copy (select 1) to '/tmp/data.txt' (header on, header off);
> ERROR: 42601: conflicting or redundant options
> =# copy (select 1) to '/tmp/data.txt' (header off, header on);
> ERROR: 0A000: COPY HEADER available only in CSV mode
>
> Looking quickly at the usages of defGetBoolean() across the code, it
> seems that we are rather consistent on a command-basis to handle such
> cases (EXPLAIN does not care, subscriptions do, etc.), while COPY is
> a mixed bag that clearly aims at checking for redundant options
> correctly. So, attached is a patch to do that, with tests for the
> various options while on it. This is not something worth a
> back-patch in my opinion.
>
> Any thoughts?
>

+1

Pavel

--
> Michael
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-09-29 07:52:17 Re: Support for NSS as a libpq TLS backend
Previous Message Fujii Masao 2020-09-29 07:32:44 Re: history file on replica and double switchover