From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ExplainProperty* and units |
Date: | 2018-03-14 17:35:47 |
Message-ID: | 20180314173547.ftcz4kaxbnhqsxkh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-03-14 13:32:10 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > If we do this, and I think we should, I'm inclined to also commit a
> > patch that renames ExplainPropertyLong
> > and changes its argument type. Because passing long is just plain
> > unhelpful for 32bit platforms and windows. We should just always use
> > 64bits here.
>
> +1 --- I'm pretty certain that function predates our requirement that
> all platforms support int64.
Cool.
> > Only thing I wonder is if we shouldn't just *remove*
> > ExplainPropertyLong and make ExplainPropertyInteger accept 64bits of
> > input - the effort of passing and printing a 64bit integer will never be
> > relevant for explain.
>
> -0.5 ... everywhere else, we mean "int32" when we say "int", and I don't
> think it's worth the potential confusion to do it differently here.
So ExplainPropertyInt{32,64}? I agree that it's not what we do
elsewhere, but I just don't see any use in actually having two
functions. I think one counter argument to your point is that it's not
an 'int' named function, it's Integer which should fit both 32 and 64
bit ones ;)
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-14 17:39:52 | Re: ExplainProperty* and units |
Previous Message | Tom Lane | 2018-03-14 17:32:10 | Re: ExplainProperty* and units |