pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: gkokolatos@pm.me, pgsql-hackers@lists.postgresql.org, Rachel Heaton <rachelmheaton@gmail.com>
Subject: Re: Add LZ4 compression in pg_dump
Date: Thu, 26 Jan 2023 21:56:32 -0600
Message-ID: <20230127035631.GV22427@telsasoft.com> (raw)
In-Reply-To: <Y8S8dkXvymKauvUh@paquier.xyz>
References: <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>
	<Y8S8dkXvymKauvUh@paquier.xyz>

On Mon, Jan 16, 2023 at 11:54:46AM +0900, Michael Paquier wrote:
> 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)?  

To circle back to this: I was not saying there's any bug.  The proposed
change was only to follow normal and existing normal conventions for
passing structs.  It could also be a pointer to const.  It's fine with
me if you say that it's intentional how it's written already.

> >> 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.





view thread (205+ messages)  latest in thread

Message-ID: <20230127035631.GV22427@telsasoft.com>
Permalink:  ../20230127035631.GV22427@telsasoft.com/
Also on:    postgresql.org/message-id/20230127035631.GV22427@telsasoft.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pryzby@telsasoft.com, michael@paquier.xyz, rachelmheaton@gmail.com
  Subject: Re: Add LZ4 compression in pg_dump
  In-Reply-To: <20230127035631.GV22427@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox