Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 16 Jan 2023 11:54:46 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: gkokolatos@pm.me, pgsql-hackers@lists.postgresql.org,
	Rachel Heaton <rachelmheaton@gmail.com>
Subject: Re: Add LZ4 compression in pg_dump
Message-ID: <Y8S8dkXvymKauvUh@paquier.xyz>
References: <IZzs7Z2ny5hRK1EhTynSg3DnCo_z-UvEJN4Q6Hf0CUHWx3BcNwt-2z5vvvvA-Z8PQL-AYiL9YQPlKylATZ_Z6HnJ55YZUHgL66H9MZQFi48=@pm.me>
 <20221219172706.GA1153@telsasoft.com>
 <srwGkjEwoQg3cdO9k1mMuIu9eEqkOA27Ikvf0cNR9mvBLVZPidKMk4fmKeVIsxVkgbVk2yeIL-Neyjb2Mkz9_ULGfk2qeYW8ZnM1iKIyklY=@pm.me>
 <20221220152610.GG1153@telsasoft.com>
 <f8Wmj1EmRT7CHBfMcg0jM_Wts_hyV22WsLWzf5X5KImQo_5CtZXHK3UjxL8Wne6g7zSccwXLNToLCINfEIPbNni53gKO17AuHplMjm-XBmA=@pm.me>
 <20221222170859.GO1153@telsasoft.com>
 <20230108194524.GA27637@telsasoft.com>
 <20230114214308.GC9837@telsasoft.com>
 <Y8SoUuqbNoMBnFJp@paquier.xyz>
 <20230116015625.GH9837@telsasoft.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="bOFKrhzd3N17EszA"
Content-Disposition: inline
In-Reply-To: <20230116015625.GH9837@telsasoft.com>
Archived-At: <https://www.postgresql.org/message-id/Y8S8dkXvymKauvUh%40paquier.xyz>
Precedence: bulk


--bOFKrhzd3N17EszA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 15, 2023 at 07:56:25PM -0600, Justin Pryzby wrote:
> On Mon, Jan 16, 2023 at 10:28:50AM +0900, Michael Paquier wrote:
>> The functions changed by 0001 are cfopen[_write](),
>> AllocateCompressor() and ReadDataFromArchive().  Why is it a good idea
>> to change these interfaces which basically exist to handle inputs?
>=20
> I changed to pass pg_compress_specification as a pointer, since that's
> the usual convention for structs, as followed by the existing uses of
> pg_compress_specification.

Okay, but what do we gain here?  It seems to me that this introduces
the risk that a careless change in one of the internal routines if
they change slight;ly compress_spec, hence impacting any of their
callers?  Or is that fixing an actual bug (except if I am missing your
point, that does not seem to be the case)? =20

>> Is there some benefit in changing compression_spec within the
>> internals of these routines before going back one layer down to their
>> callers?  Changing the compression_spec on-the-fly in these internal
>> paths could be risky, actually, no?
>=20
> I think what you're saying is that if the spec is passed as a pointer,
> then the called functions shouldn't set spec->algorithm=3Dsomething.

Yes.  HEAD makes sure of that, 0001 would not prevent that.  So I am a
bit confused in seeing how this is a benefit.
--
Michael

--bOFKrhzd3N17EszA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmPEvHYACgkQnvQgOdby
QH0dXQ/8DP9FUhAk4QO0TljyR7vX/D9eY4JAaKJu/o84cQ/VA1M4533eWMsI+dmy
qEjVoFYPN6juTbefgLlh3AuTS5qYq6Edsx4YopE2kCWQvQJpNaABvL0Oel5kxHTN
YenJTViaq6beU/2FiNJ6QibelTEtQhudXolnU22rzcTZ0xjVOIi1igltjD1MXWYQ
OOb+XlFpFWcpWe9An+TCVQl7WfO6zDZJy21hliRswEv8pseaSyqnGb2OXkFqb1Ps
/grn8NLyUTmk89/tpF9wZ1aB2hm9f9Up0h1hRKsap+Rabu/odtL1tMPDRFTCa9i4
VfNN6X4zCSeEFGf/BsVTfFqHGx1OonrNSSEQZLgPY7S+PG2BRT2YzBJtQ8P6DfPm
wJ6CK0Pq7LUbWg/cjtHWWFYF68LjUBZ6h4AggMbKbhS2cMsNtPX8fkOBie17W9KM
7ufu613FK4jpfM0K14if0CQxVUhrQjjIR4sL0NZJWA4rOCvgm3KuZR+UzvqbLhfi
DfcnziT+HNyG56C5miW5KDD8vFh1N68eATKZg+f8JB9zL22sJP4CGju80OTpM2+w
2UpC1hYF4ZaSPjbstce6Br9p9uXZ39UDyx0/2K+J5LEF2qZobaB9vhjm9nwvFrfX
ZHADWfEF+Mn20LRK+T54QtiF07RdLmTpMEqo2YHA1aO+X3RK7uE=
=hE80
-----END PGP SIGNATURE-----

--bOFKrhzd3N17EszA--