I wrote:
> In short, I'm willing to drop my opposition to the original form
> of the patch.
Original version applied with some minor tweaks (notably, pg_relpages
had the same problem).
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, this followup patch is wrong though -- the SQL definition is still
> using BIGINT where it should be using double. And the other changes to
> use BIGINT where the original values were int4 seem unnecessary.
I'm on this one now ...
Tatsuhito Kasahara <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Most places where we've dealt with this before, we use double, which is
>> guaranteed to be available whereas uint64 is not ...
> Oh I see.
> I fix the patch.
> # I changed "max_avail" and "free_space" to double.
I took a closer
Tatsuhito Kasahara wrote:
> Tatsuhito Kasahara wrote:
> > I fix the patch.
> Oops, I forgot to attach the patch for pgstattuple.sql.
> I send it again.
Hmm, this followup patch is wrong though -- the SQL definition is still
using BIGINT where it should be using double. And the other changes to
us
On Mon, Feb 25, 2008 at 11:50:11AM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> Is there any currently supported platform which does not have
> >>> uint64?
> >>
> >> I don't know, and neither do you.
>
> > Maybe we should look at some reasonable way
Tom Lane napsal(a):
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Maybe we should just bite the bullet, and implement int64 emulation
for platforms that don't provide one?
Why? Workarounds such as "use double where needed" have served us
perfectly fine so far, with far less effort and notati
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Maybe we should just bite the bullet, and implement int64 emulation
> for platforms that don't provide one?
Why? Workarounds such as "use double where needed" have served us
perfectly fine so far, with far less effort and notational ugliness
than t
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane napsal(a):
Most places where we've dealt with this before, we use double, which is
guaranteed to be available whereas uint64 is not ...
Is this requirement still valid?
Yes.
Maybe we should just bite the bullet, and implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 25 Feb 2008 11:21:18 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> > IIRC we are going to change datetime to integer for 8.4.
>
> We are going to change the *default* to integer.
Thank goodness. Now I can stop recompiling rpms. Thanks for thi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Is there any currently supported platform which
>>> does not have uint64?
>>
>> I don't know, and neither do you.
> Maybe we should look at some reasonable way of getting the info out of a
> compiled instance. How about if we get p
Tom Lane wrote:
Is there any currently supported platform which
does not have uint64?
I don't know, and neither do you.
Maybe we should look at some reasonable way of getting the info out of a
compiled instance. How about if we get pg_config to output the value of
INT64_IS_
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> Most places where we've dealt with this before, we use double, which is
>> guaranteed to be available whereas uint64 is not ...
> Is this requirement still valid?
Yes.
> Is there any currently supported platform which
> does not
Tom Lane napsal(a):
Tatsuhito Kasahara <[EMAIL PROTECTED]> writes:
In pgstatindex.c and pgstattuple.sql, some variables are defined with
int type. So when we try to get informations about a large index by using
pgstatindex, we get strange value of size and density.
Because the values exceed int-
Tatsuhito Kasahara wrote:
> I fix the patch.
Oops, I forgot to attach the patch for pgstattuple.sql.
I send it again.
Best regards.
--
NTT OSS Center
Tatsuhito Kasahara
kasahara.tatsuhito _at_ oss.ntt.co.jp
diff -crN postgresql-8.3.0.org/contrib/pgstattuple/pgstatindex.c
postgresql-8.3.0/contr
Hi.
Tom Lane wrote:
>> I think that max_avail and free_space should be uint64.
> Most places where we've dealt with this before, we use double, which is
> guaranteed to be available whereas uint64 is not ...
Oh I see.
I fix the patch.
# I changed "max_avail" and "free_space" to double.
Best rega
Tatsuhito Kasahara <[EMAIL PROTECTED]> writes:
> In pgstatindex.c and pgstattuple.sql, some variables are defined with
> int type. So when we try to get informations about a large index by using
> pgstatindex, we get strange value of size and density.
> Because the values exceed int-max.
> ...
> I
Hi.
In pgstatindex.c and pgstattuple.sql, some variables are defined with
int type. So when we try to get informations about a large index by using
pgstatindex, we get strange value of size and density.
Because the values exceed int-max.
# Like following output. I used pgstatindex just after data
17 matches
Mail list logo
