Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute
Date
Msg-id CAA4eK1JAwxmhdRVOxbrtyhAOpZDfjZAq3fdDzxN=scvGPWf8Mw@mail.gmail.com
Whole thread Raw
In response to Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jun 19, 2020 at 9:18 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote:
> >> column_no was used for that purpose in the past, but commit 0e319c7ad7
> >> changed that.
>
> > Yeah, but not sure why?  By looking at the commit message and change
> > it is difficult to say why it has been removed?  Tom has made that
> > change but I don't think he would remember it, in any case, adding him
> > in the email to see if he remembers anything related to it.
>
> Hm, no, that commit is nearly old enough to vote :-(
>
> However, I dug around in the archives, and I found what seems to be
> the relevant pghackers thread:
>
> https://www.postgresql.org/message-id/flat/28188.1064615075%40sss.pgh.pa.us#8e0c07452bb7e729829d456cfb0ec485
>
> Looking at that, I think I concluded that these error cases are not useful
> indications of problems within the specific column's data, but most likely
> indicate corruption at the level of the overall COPY line format; ergo the
> line-level context display is sufficient.  You could quibble with that
> conclusion of course, but if you agree with it, then the column_no
> parameter is useless here.
>

I don't see any problem with your conclusion and the fact that we
haven't came across any case which requires column_no in such messages
favors your conclusion.

>  I probably just failed to notice at the time
> that the parameter was otherwise unused, else I would have removed it.
>

No issues, I can take care of this (probably in HEAD only).

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans
Next
From: David Rowley
Date:
Subject: Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans