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 revie
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 the
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 broadcast)-
Where are we on this?
---
Tom Dunstan wrote:
> 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
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
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
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
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
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
integrity
"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
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
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
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
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
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
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 mi
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
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?
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 in
19 matches
Mail list logo
