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