Re: [HACKERS] Dbsize backend integration - Mailing list pgsql-patches

From Dave Page
Subject Re: [HACKERS] Dbsize backend integration
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E490E8CF@ratbert.vale-housing.co.uk
Whole thread Raw
Responses Re: [HACKERS] Dbsize backend integration  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 03 July 2005 17:10
> To: Dawid Kuroczko
> Cc: Andreas Pflug; Dave Page; Bruce Momjian;
> PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
>
> Dawid Kuroczko <qnex42@gmail.com> writes:
> > Oh, I think pg_dbfile_size is best so far.
>
> I think it's by far the ugliest suggestion yet :-(

Why? It does exactly what it says on the tin! It might not be that nice,
but it does describe what it does - and noone yet has come up with
anything less ambiguous or misleading imho.

> Andreas's suggestion of having just one function with a bool parameter
> might be a workable compromise.

Aside from the fact that's a change to the API that we had settled on,
it doesn't solve the actual problem of needing a suitable name for a
function that returns the size of a table /or/ index. pg_relation_size()
or pg_table_size() can't be used for precisely the reason they were
rejected for that purpose in the first place.

Regards, Dave.

pgsql-patches by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Next
From: Neil Conway
Date:
Subject: silence GCC4 warning