Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-20 Thread Andrew Dunstan
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

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-20 Thread Martijn van Oosterhout
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

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-19 Thread Tom Dunstan
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 su

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-19 Thread Gregory Stark
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > I'm not a big fan of ordering columns to optimise record layout, except in the > most extreme cases (massive DW type apps). I think visible column order should > be logical, not governed by physical considerations. Well as long as we're talking "shou

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-19 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > 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

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-19 Thread Andrew Dunstan
Alvaro Herrera wrote: Andrew Dunstan wrote: As for efficiency, I agree with what Tom says about alignment and padding dissolving away any perceived advantage in most cases. If we ever get around to optimising record layout we could revisit it. I don't, because there are always those

Re: [HACKERS] [PATCHES] Enums patch v2

2006-12-19 Thread Alvaro Herrera
Andrew Dunstan wrote: > As for efficiency, I agree with what Tom says about alignment and > padding dissolving away any perceived advantage in most cases. If we > ever get around to optimising record layout we could revisit it. I don't, because there are always those that are knowledgeable enou