Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Enums patch v2

From: Tom Dunstan <pgsql(at)tomd(dot)cc>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Enums patch v2
Date: 2006-12-20 01:39:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera wrote:
> I don't, because there are always those that are knowledgeable enough to
> know how to reduce space lost to padding.  So it would be nice to have
> 2-byte enums on-disk, and resolve them based on the column's typid.  But
> then, I'm not familiar with the patch at all so I'm not sure if it's
> possible.

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 function (and cast-to-text function), because output 
functions do not get provided the oid of the type that they're dealing 
with, for security reasons IIRC. It was never clear to me why I/O 
functions should ever be directly callable by a user (and hence open to 
security issues), but apparently it was enough to purge any that were 
designed like that from the system, so I wasn't going to go down that 
road with the patch.



In response to


pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2006-12-20 01:44:26
Subject: Re: effective_cache_size vs units
Previous:From: Matthew O'ConnorDate: 2006-12-20 01:33:59
Subject: Re: Autovacuum Improvements

pgsql-patches by date

Next:From: Tom DunstanDate: 2006-12-20 02:00:48
Subject: Re: Enums patch v2
Previous:From: Tom DunstanDate: 2006-12-20 01:23:02
Subject: Re: Enums patch v2

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group