On Sat, 2017-09-02 at 18:06 -0400, Tom Lane wrote:
> Because it's really an OID under the hood.
I see.
> > In any use cases, that I know,
> > ENUM 255 values (1 byte) more then enough.
> Only if you consider each enum type in isolation (and even then, I'd
> dispute your argument that nobody has u
=?UTF-8?Q?=D0=9E=D0=BB=D0=B5=D0=B3_?=
=?UTF-8?Q?=D0=A1=D0=B0=D0=BC=D0=BE=D0=B9=D0=BB=D0=BE=D0=B2?=
writes:
> May I ask the question here or I must go to the pgsql-hackers?
> Why does ENUM type have 4 byte size?
Because it's really an OID under the hood.
> In any use cases, that I know,
> ENUM
Elein Mustain
el...@varlena.com
510-637-9106
> On Mar 13, 2016, at 7:22 PM, Alvaro Herrera wrote:
>
> Elein wrote:
>
> Hi Elein,
>
>> * When an insert into an enum column fails give the person a hint as to
>> valid values
>
>> -- Lousy message. Show enum list.
>> insert into badinfo val
Joshua D. Drake wrote:
> On 03/14/2016 08:48 AM, Alvaro Herrera wrote:
> >(*) Yes, I'm being a bit sarcastic here, sorry about that. I actually
> >learned quite a bit of database design and related topics by translating
> >the "General Bits" column she used to write, many years ago.
>
> Your ans
On Sun, Mar 13, 2016 at 10:20:05PM -0400, Melvin Davidson wrote:
> The point is, they are an archaic data type and it's a hell of a lot easier
> to use Foreign Keys to insure integrity.
So don't use them? Nobody, surely, is forcing you to use enums.
I recall when enums were added. I recall thin
On Mon, Mar 14, 2016 at 12:07 PM, Joshua D. Drake
wrote:
> On 03/14/2016 09:02 AM, David G. Johnston wrote:
>
> The one nice thing about enums is that you get two concepts in one
>> column - a human readable label and a system used ordering.
>>
>> i.e., "SELECT enum_value FROM tbl ORDER BY enum_
On 03/14/2016 09:02 AM, David G. Johnston wrote:
The one nice thing about enums is that you get two concepts in one
column - a human readable label and a system used ordering.
i.e., "SELECT enum_value FROM tbl ORDER BY enum_value" actually
gives you a meaningful order without having to carr
On Mon, Mar 14, 2016 at 8:52 AM, Joshua D. Drake
wrote:
>
> If improved enough, maybe we could get to a
>> point where they could actually be used; otherwise why the heck did we
>> let the feature in the database in the first place? I think all these
>> "use a lookup table, you silly!" answers
On Mon, Mar 14, 2016 at 8:48 AM, Alvaro Herrera
wrote:
> Joshua D. Drake wrote:
> > On 03/11/2016 03:19 PM, Elein wrote:
> >
> > >An unused (yet) enum type cannot display the enum ranges. An empty table
> > >containing that type cannot display enum ranges.
> > >
> > >The example selects were what
On 03/14/2016 08:48 AM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
On 03/11/2016 03:19 PM, Elein wrote:
An unused (yet) enum type cannot display the enum ranges. An empty table
containing that type cannot display enum ranges.
The example selects were what I did to figure out that enum_range
Joshua D. Drake wrote:
> On 03/11/2016 03:19 PM, Elein wrote:
>
> >An unused (yet) enum type cannot display the enum ranges. An empty table
> >containing that type cannot display enum ranges.
> >
> >The example selects were what I did to figure out that enum_ranges only
> >worked on existing data.
On 03/11/2016 03:19 PM, Elein wrote:
An unused (yet) enum type cannot display the enum ranges. An empty table
containing that type cannot display enum ranges.
The example selects were what I did to figure out that enum_ranges only
worked on existing data. Sorry if they were confusing. But the w
Elein wrote:
Hi Elein,
>* When an insert into an enum column fails give the person a hint as to
> valid values
> -- Lousy message. Show enum list.
> insert into badinfo values ('green');
> ERROR: invalid input value for enum rainbow: "green"
> LINE 1: insert into badinfo values ('green');
The post refers to the generic unmanageability of enums in genaral, it just
uses MySQL as a reference basis.
Google evil enum and you will find several articles that all say the same
thing.
To be specific,even in PostgreSQL, there is no easy way to delete enum
values once they exist, other than pla
Melvin Davidson wrote:
> Enums are evil!
> http://www.lornajane.net/posts/2010/is-enum-evil
???
This post is about MySQL's enums, which aren't really related to
Postgres enums:
"In order to change the allowed values of an enum column, we
need to issue an alter table statement [.
Elein Mustain
el...@varlena.com
510-637-9106
> On Mar 11, 2016, at 3:45 PM, David G. Johnston
> wrote:
>
>> On Fri, Mar 11, 2016 at 4:19 PM, Elein wrote:
>
>> An unused (yet) enum type cannot display the enum ranges. An empty table
>> containing that type cannot display enum ranges.
>
>
On Fri, Mar 11, 2016 at 4:19 PM, Elein wrote:
> An unused (yet) enum type cannot display the enum ranges. An empty table
> containing that type cannot display enum ranges.
>
Yes, it can.
CREATE TYPE rainbow AS enum ('red','orange','yellow','blue','purple');
SELECT enum_range(null::rainbow);
e
The point is that enum information belongs to a type, not a column value of
that type.
This is the difference between a class and a class instance.
If you get that, you understand.
The workaround suggested only works if some non-empty row in some table has a
column defined to be that enum
On Fri, Mar 11, 2016 at 2:55 PM, Melvin Davidson
wrote:
> Enums are evil!
> http://www.lornajane.net/posts/2010/is-enum-evil
>
>
Using red background is evil :)
I'll disagree on the premise but will agree that without a better
implementation and handling of change our implementation makes using
On Fri, Mar 11, 2016 at 2:36 PM, Elein wrote:
>
> > Bug/Improvement:
> >
> >Enums belong to types, not to column values.
> >
> >* Create a built in function, like enum_range( type ), independent of
> tables
> > that shows a type's enum values.
> >create or replace function en
On 3/11/2016 1:36 PM, Elein wrote:
>Bug/Improvement:
>
>Enums belong to types, not to column values
I've read this post twice, and I'm still unclear on what you're saying
is a problem, and what your proposed solution is...
--
john r pierce, recycling bits in santa cruz
--
Sent
On Fri, Mar 11, 2016 at 4:36 PM, Elein wrote:
>
> > Bug/Improvement:
> >
> >Enums belong to types, not to column values.
> >
> >* Create a built in function, like enum_range( type ), independent of
> tables
> > that shows a type's enum values.
> >create or replace function en
Thank you for the message Tom; sounds great. I'll try that out, will check
on the planner's resultant behavior and email back.
Peter
On Sat, May 23, 2015 at 12:35 PM, Tom Lane wrote:
> Peter Swartz writes:
> > suppose the foreign database adds a value to the enum, and the foreign
> > table no
Peter Swartz writes:
> suppose the foreign database adds a value to the enum, and the foreign
> table now has rows with this new value, while the local definition of the
> enum remains unchanged. Obviously, the appropriate action on my part is to
> maintain consistency of enum definition between
Thank you for the note Ian. I definitely see your point about the onus
being on the local database to maintain the definition of the remote
table. Do you or anyone have this list have any experience with the
resulting behavior if the definition of the enum were to become out of sync
between the l
On 21/05/15 04:23, Peter Swartz wrote:
> I'm creating a foreign table (foo_table) in database_a. foo_table lives in
> database_b.foo_table has an enum (bar_type) as one of its columns. Because
> this enum is in database_b, the creation of the foreign table fails in
> database_a. database_a doesn't
On Fri, Sep 27, 2013 at 1:37 AM, Arjen Nienhuis wrote:
>> Are there any caveats of this solution and may be there is a better one?
>
> Why don't you just create a new ENUM with fewer values? You can use:
> ALTER TABLE ... SET DATA TYPE ... USING col1::text::new_enum_type;
> You might need to recre
On Sep 26, 2013 9:20 PM, "Sergey Konoplev" wrote:
>
> Hi,
>
> AIU we have no ability to drop a label from ENUM currently, and there
> are no plans to add this feature in the nearest future.
>
> I came to a workaround via DOMAIN, here it is:
>
> CREATE TYPE ref AS ENUM ('aaa', 'bbb');
>
> CREATE DO
On ons, 2009-11-18 at 22:33 -0800, Scott Bailey wrote:
> The only I/O functions I'm aware of are
> send, recv, in and out. What controls converting from/to wire and
> on-disk formats?
send and recv
> And why is wire format little endian and disk big endian?
The wire format is network order (w
Tom Lane wrote:
Scott Bailey writes:
I'm trying to better understand the internals of Postgres, and I'm
looking at the enum type. The docs say that an enum value is stored on
disk as 4 bytes. But enum_send() returns a bytea representing the actual
text of the value and not the index of that v
Scott Bailey writes:
> I'm trying to better understand the internals of Postgres, and I'm
> looking at the enum type. The docs say that an enum value is stored on
> disk as 4 bytes. But enum_send() returns a bytea representing the actual
> text of the value and not the index of that value. So
Xai wrote:
Is there a query i can use to get the fields of an Enum, just in case
someone needs it for the client application.
select e.enumlabel from pg_enum as e join pg_type as t on (t.typtype='e'
and e.enumtypeid=t.typbasetype) where t.typname = $1 order by e.enumtypid;
I think. or
32 matches
Mail list logo
