Re: Add LZ4 compression in pg_dump
От | Michael Paquier |
---|---|
Тема | Re: Add LZ4 compression in pg_dump |
Дата | |
Msg-id | Y8S8dkXvymKauvUh@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Add LZ4 compression in pg_dump (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Add LZ4 compression in pg_dump
Re: Add LZ4 compression in pg_dump |
Список | pgsql-hackers |
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? > > 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)? >> 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? > > 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=something. 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
Вложения
В списке pgsql-hackers по дате отправления: