> -----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.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"Dave Page" <dpage@vale-housing.co.uk> writes:
> 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.

Rejected by whom? pg_relation_size is an excellent choice for that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom Lane wrote:
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > 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.
>
> Rejected by whom? pg_relation_size is an excellent choice for that.

We mostly tell people that table and relation are synonmous. Though
there is a distinction, it seems error-prone to rely on that distinction
in the API.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian wrote:
> Tom Lane wrote:
> > "Dave Page" <dpage@vale-housing.co.uk> writes:
> > > 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.
> >
> > Rejected by whom? pg_relation_size is an excellent choice for that.
>
> We mostly tell people that table and relation are synonmous. Though
> there is a distinction, it seems error-prone to rely on that distinction
> in the API.

I am starting to warm up to the idea of using "relation" as the combined
total. Was that the proposal? Are we prepared to make that distinction
in other places?

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq