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