On Sun, Mar 10, 2019 at 4:47 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Julien Rouhaud <rjuju...@gmail.com> writes: > > On Sat, Mar 9, 2019 at 10:04 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I tried this, and it seems to work pretty well. The first of the two > >> attached patches just teaches guc.c to support units for float values, > >> incidentally allowing "us" as an input unit for time-based GUCs. > > > Why not allowing third party extensions to declare a GUC stored in us? > > I think that adding a new base unit type (GUC_UNIT_US) is possible but > I'm disinclined to do it on the basis of zero evidence that it's needed. > Only three of the five already-known time units are allowed to be base > units (ms, s, min are but d and h aren't) so it's not like there's no > precedent for excluding this one. Anyway, such a patch would be mostly > orthogonal to what I've done here, so it should be considered on its > own merits. > (BTW, if we're expecting to have GUCs that are meant to measure only > very short time intervals, maybe it'd be more forward-looking for > their base unit to be NS not US.)
That's fair. > >> 2. It's always bugged me that we don't allow fractional unit > >> specifications, say "0.1GB", even for GUCs that are integers underneath. > >> That would be a simple additional change on top of this, but I didn't > >> do it here. > > > It annoyed me multiple times, so +1 for making that happen. > > OK, will do. Thanks!
