Re: custom function for converting human readable sizes to bytes - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: custom function for converting human readable sizes to bytes
Date
Msg-id CAFj8pRBfY6-FygbbpCrcqP7QuifpzTDTPzTWMTfDSRdYVmwr8Q@mail.gmail.com
Whole thread Raw
In response to Re: custom function for converting human readable sizes to bytes  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: custom function for converting human readable sizes to bytes
List pgsql-hackers
Hi


-1 from me.  I don't think we should muck with the way pg_size_pretty works.

new update - I reverted changes in pg_size_pretty

Hi,

I didn't check out earlier versions of this patch, but the latest one still changes pg_size_pretty() to emit PB suffix.

I don't think it is worth it to throw a number of changes together like that.  We should focus on adding pg_size_bytes() first and make it compatible with both pg_size_pretty() and existing GUC units: that is support suffixes up to TB and make sure they have the meaning of powers of 2^10, not 10^3.  Re-using the table present in guc.c would be a plus.

Next, we could think about adding handling of PB suffix on input and output, but I don't see a big problem if that is emitted as 1024TB or the user has to specify it as 1024TB in a GUC or argument to pg_size_bytes(): an minor inconvenience only.

Last version still support BP in pg_size_pretty. It isn't big change. PB isn't issue.

We have to do significant decision - should to support SI units in pg_size_bytes? We cannot to change it later. There is disagreement for SI units in pg_size_pretty, so SI units in pg_size_bytes can be inconsistent.

Regards

Pavel
 

--
Alex


pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: COPY (... tab completion
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport