[PHP-DEV] ext/pgsql: pg_put_line deprecation proposal

I would like to know if it would be fine to deprecate pg_put_line.

Reasoning is PQPutLine is part of the obsolete list of calls for COPY purpose since the PostgreSQL protocol 3.0 version (supported since postgresql 7.4 released about 20 years ago, see New client-to-server protocol regarding COPY).

Related PR.

Cheers

Hi,

Il 20/05/2024 14:03, David CARLIER ha scritto:

I would like to know if it would be fine to deprecate pg_put_line <http://pg_put_line>.

Reasoning is PQPutLine is part of the obsolete list of calls for COPY purpose <PostgreSQL: Documentation: 16: 34.10. Functions Associated with the COPY Command; since the PostgreSQL protocol 3.0 version (supported since postgresql 7.4 released about 20 years ago, see New client-to-server protocol regarding COPY <https://www.postgresql.org/docs/7.4/release-7-4.html&gt;\).

Related PR <https://github.com/php/php-src/pull/14250&gt;\.

I have fond memories of using pg_put_line several years ago!

It is true that it's obsolete and although they still work, they are deprecated in libpq.

However, I have a few remarks...

If you're targeting the protocol 3.0 change, what is deprecated is the pg_put_line('\\.') call that needed to be sent before calling pg_end_copy().

pg_put_line() is used to send data, not just the end message.

Hence, the UPGRADING message misrepresents the reason why pg_put_line() is deprecated.

In case we really decide to deprecate pg_put_line on the PHP side, so should be pg_end_copy.

However we don't provide a full alternative to it, because pg_copy_from only accepts arrays, according to the documentation. As such, there is no real alternative for "streaming" data without storing it all in memory.

Unless we provide it, I would vote against deprecating them.

My opinion could change if pg_copy_from() worked with generators, but I still think the two function still have a place for those needing low-level access.

Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Hi Matteo,

On Mon, 20 May 2024 at 14:08, Matteo Beccati <php@beccati.com> wrote:

Hi,

Il 20/05/2024 14:03, David CARLIER ha scritto:

I would like to know if it would be fine to deprecate pg_put_line
<http://pg_put_line>.

Reasoning is PQPutLine is part of the obsolete list of calls for COPY
purpose
<https://www.postgresql.org/docs/current/libpq-copy.html#LIBPQ-PQPUTLINE> since the PostgreSQL protocol 3.0 version (supported since postgresql 7.4 released about 20 years ago, see New client-to-server protocol regarding COPY <https://www.postgresql.org/docs/7.4/release-7-4.html>).

Related PR <https://github.com/php/php-src/pull/14250>.

I have fond memories of using pg_put_line several years ago!

It is true that it’s obsolete and although they still work, they are
deprecated in libpq.

However, I have a few remarks…

If you’re targeting the protocol 3.0 change, what is deprecated is the
pg_put_line(‘\.’) call that needed to be sent before calling pg_end_copy().

pg_put_line() is used to send data, not just the end message.

Hence, the UPGRADING message misrepresents the reason why pg_put_line()
is deprecated.

In case we really decide to deprecate pg_put_line on the PHP side, so
should be pg_end_copy.

However we don’t provide a full alternative to it, because pg_copy_from
only accepts arrays, according to the documentation. As such, there is
no real alternative for “streaming” data without storing it all in memory.

Thanks for your thoughts, I ve overlooked this.

Unless we provide it, I would vote against deprecating them.

My opinion could change if pg_copy_from() worked with generators, but I
still think the two function still have a place for those needing
low-level access.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

Hi David,

Il 21/05/2024 07:53, David CARLIER ha scritto:

Thanks for your thoughts, I ve overlooked this.

No worries!

However, we might want to expose the functionalities from PQputCopyData and PQputCopyEnd and perhaps PQgetCopyData at some point. :wink:

Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/