I am putting this in the patches queue so it is not lost. I believe
Neil is working applying this.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
Neil Conway wrote:
On Thu, 2007-02-01 at 22:50 -0500, Bruce Momjian wrote:
Where are we on this?
I can commit to reviewing this. The patch looked fairly solid on a quick
glance through, but I won't have the cycles to review it properly for a
week or two.
I've brought this up to date with
On Thu, 2007-02-01 at 22:50 -0500, Bruce Momjian wrote:
Where are we on this?
I can commit to reviewing this. The patch looked fairly solid on a quick
glance through, but I won't have the cycles to review it properly for a
week or two.
-Neil
---(end of
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
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
Tom Dunstan wrote:
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
I'm sorry I missed the original discussions, but I have to ask: Why do
we want enums in core?
On Tue, Dec 19, 2006 at 08:09:47AM +, Heikki Linnakangas wrote:
Tom Dunstan wrote:
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
I'm sorry I missed the
Heikki Linnakangas [EMAIL PROTECTED] writes:
Ignoring my general dislike of enums, I have a few issues with the patch
as it is:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why
do we want enums in core? The only potential advantage I can see over
using a look-up table and FK references is performance.
The difference is that foreign-key-referenced data is part of your data
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
1. What's the point of having comparison operators for enums? For most
use cases, there's no natural ordering of enum values.
If you would like to be able to index enum columns, or even GROUP BY one,
you need those; whether
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 enough
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
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
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 shoulds the
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why do
we want enums in core? The only potential advantage I can see over using
a look-up table and FK references is performance.
Well, there are a few things. Sometimes its tidiness, sometimes
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
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
Hi all
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
This version contains sgml documentation, and contains the missing
bounds checks and error codes noted
18 matches
Mail list logo
