Hi, In <CAD21AoDr13=dx+k8gmqnr5_by+nskyn4mbswn0khqncl6xu...@mail.gmail.com> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 28 Feb 2025 11:50:39 -0800, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> I initially thought it would be acceptable to stop > NextCopyFromRawFields exposed since NextCopyFrom() could serve as an > alternative. For example, the NextCopyFromRawFields() function was > originally exposed in commit 8ddc05fb01ee2c primarily to support > extension modules like file_fdw but file_fdw wasn't utilizing this > API. I pushed the patch without the above change. Unfortunately, this > commit subsequently broke file_text_array_fdw[1] and made BF animal > crake unhappy[2]. > > [1] https://github.com/adunstan/file_text_array_fdw > [2] > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2025-02-28%2018%3A47%3A02 Thanks for the try! > Upon examining file_text_array_fdw more closely, I realized that > NextCopyFrom() may not be a suitable replacement for > NextCopyFromRawFields() in certain scenarios. Specifically, > NextCopyFrom() assumes that the caller has prior knowledge of the > source data's column count, making it inadequate for cases where > extensions like file_text_array_fdw need to construct an array of > source data with an unknown number of columns. In such situations, > NextCopyFromRawFields() proves to be more practical. Given these > considerations, I'm now leaning towards implementing the proposed > change. Thoughts? You suggest that we re-export NextCopyFromRawFields() (as a wrapper of static inline version) for backward compatibility, right? It makes sense. We should keep backward compatibility because there is a use-case of NextCopyFromRawFields(). Thanks, -- kou
