Re: FSM rewrite committed, loose ends - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: FSM rewrite committed, loose ends
Date
Msg-id 48E50FD5.7050805@enterprisedb.com
Whole thread Raw
In response to Re: FSM rewrite committed, loose ends  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
Robert Treat wrote:
> On Thursday 02 October 2008 08:37:59 Tom Lane wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> There's currently two variants of both pg_relation_size and
>>> pg_total_relation_size, one takes an OID and one takes a relation name
>>> as argument. Any objections to having just one of each function, taking
>>> a 'regclass'? The user-visible behavior wouldn't change, but I thought
>>> I'd ask first in case I'm missing something.
>> Um, it would only not change for someone typing
>> pg_relation_size('literal').  Something like this:
>>
>>     select sum(pg_relation_size(relname)) from pg_class
>>
>> would fail for lack of an implicit cast from name to regclass.
>> Now the above is pretty stupid --- it would be faster and more
>> schema-safe to be passing pg_class.oid --- so maybe we don't care
>> about breaking it.
> 
> I would be more concerned about people doing:
> 
> select pg_relation_size(tablename) from pg_tables; 
> 
> since pg_tables is presented as a more user-friendly option to something like 
> pg_class this might be something more widely used, plus we don't have the 
> easy way out of just telling them to use the oid instead like we do with 
> pg_class. 

That won't generally work either, because "tablename" is not 
schema-qualified. With a WHERE clause, maybe.

I'm going go ahead with this change. If an unlucky query stops working, 
fixing it is just a matter of adding a cast.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: Block-level CRC checks
Next
From: Robert Treat
Date:
Subject: Re: Block-level CRC checks