Hi,
On 2018-02-12 09:54:29 +1030, Andrew Dunstan wrote:
> The idea is to have an append-only list of labels
> which would not obey transactional semantics, and would thus help us
> avoid the pitfalls of enums - there wouldn't be any rollback of an
> addition.
FWIW, I think we can resolve the issu
They'd refer to separate enums.
I originally thought an enum was a good comparison for this feature, but
I'm no longer sure that it is. A text-based ordering would be desired
rather than the label index.
A better comparison may be a two-column lookup table:
-- create
CREATE TABLE cities (id bigs
> On Feb 12, 2018, at 6:35 PM, Tom Lane wrote:
>
> Andrew Kane writes:
>> Thanks everyone for the feedback. The current enum implementation requires
>> you to create a new type and add labels outside a transaction prior to an
>> insert.
>
> Right ...
>
>> Since enums have a fixed number of la
> On Feb 12, 2018, at 5:08 PM, Andrew Kane wrote:
>
> Thanks everyone for the feedback. The current enum implementation requires
> you to create a new type and add labels outside a transaction prior to an
> insert.
>
> -- on table creation
> CREATE TYPE city AS ENUM ();
> CREATE TABLE "users"
Andrew Kane writes:
> Thanks everyone for the feedback. The current enum implementation requires
> you to create a new type and add labels outside a transaction prior to an
> insert.
Right ...
> Since enums have a fixed number of labels, this type of feature may be
> better off as a property you
Thanks everyone for the feedback. The current enum implementation requires
you to create a new type and add labels outside a transaction prior to an
insert.
-- on table creation
CREATE TYPE city AS ENUM ();
CREATE TABLE "users" ("city" city);
-- on insert
ALTER TYPE city ADD VALUE IF NOT EXISTS '
> On Feb 10, 2018, at 7:46 PM, Andrew Kane wrote:
>
> Hi,
>
> I'm hoping to get feedback on an idea for a new data type to allow for
> efficient storage of text values while keeping reads and writes
> user-friendly. Suppose you want to store categorical data like current city
> for users. Th
On 02/11/2018 10:06 PM, Thomas Munro wrote:
> On Mon, Feb 12, 2018 at 12:24 PM, Andrew Dunstan
> wrote:
>> On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote:
>>> Andrew Kane writes:
A better option could be a new "dynamic enum" type, which would have
similar storage requirements as an en
On Mon, Feb 12, 2018 at 12:24 PM, Andrew Dunstan
wrote:
> On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote:
>> Andrew Kane writes:
>>> A better option could be a new "dynamic enum" type, which would have
>>> similar storage requirements as an enum, but instead of labels being
>>> declared ahead o
On Mon, Feb 12, 2018 at 9:10 AM, Tom Lane wrote:
> Andrew Kane writes:
>> A better option could be a new "dynamic enum" type, which would have
>> similar storage requirements as an enum, but instead of labels being
>> declared ahead of time, they would be added as data is inserted.
>
> You realiz
Andrew Kane writes:
> A better option could be a new "dynamic enum" type, which would have
> similar storage requirements as an enum, but instead of labels being
> declared ahead of time, they would be added as data is inserted.
You realize, of course, that it's possible to add labels to an enum
11 matches
Mail list logo
