This patch consists of two c functions to expose n_live_tuples and
n_dead_tuples, SQL functions to expose them to SQL land, and
corresponding fields added to pg_stat_all_tables.
This has been discussed in general. The purpose is to allow
autovacuum-esq conditional vacuuming and clustering usi
Martijn van Oosterhout wrote:
Also, it's not just I/O functions that are the issue, consider the
enum-to-integer cast.
er, what cast? :-)
IIRC Tom hasn't provided one. If you don't break the enum abstraction
there should be no need for one, and given the implementation it's not
quite tri
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>>> Perhaps an array of int4 would be better? How much
> Done
> http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
>>> The patch needs more cleanup before applying, too, eg make comments
>>> match code, get rid of unused keywords added to gram.y.
> Cl
>> Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
--
Teodor Sigaev
On Wed, Dec 20, 2006 at 01:39:58AM +, Tom Dunstan wrote:
> Not with this patch, and AFAIK not possible generally, without writing
> separate I/O functions for each type. I'd love to be able to do that,
> but I don't think it's possible currently. The main stumbling block is
> the output func