On Fri, Jun 19, 2020 at 9:18 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao > > <masao.fu...@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
