From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] A real currency type |
Date: | 2006-03-21 22:55:09 |
Message-ID: | 4730.1142981709@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Let me put it this way: if this is to progress beyond just a contrib
> module, it needs to go all the way (special syntax, pg_dump, etc). I'm
> not sure if I'm that enamoured with it to want all that.
My feelings in a nutshell ;-)
> The only way to avoid that is if both the type and the backing table
> are included in the standard distribution and we forbid user changes.
I was thinking something more like a CREATE ENUM TYPE command that
specifically lists the enum values, and some extension of that to cater
for tagged types, and the values are put into a system catalog that the
user doesn't manipulate directly. I don't see why it's a good idea to
put control of the backing table in the user's hands. Yes, you can
think of advanced applications where it's useful to have random
additional stuff in the table, but that's exactly the point at which you
normally have to get down-and-dirty with some C code --- after all, what
is standardized code going to *do* with the additional stuff? Nothing,
that's what. If the argument for this is to make it simple to make
simple enum and tagged types, then I don't think that the design should
be centered on allowing extra stuff.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-03-21 23:07:07 | Re: [GENERAL] A real currency type |
Previous Message | Neil Conway | 2006-03-21 22:47:58 | Re: index scan backward plan question |
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-03-21 23:00:08 | Re: Automatically setting work_mem |
Previous Message | Tom Lane | 2006-03-21 22:47:00 | Re: Automatically setting work_mem |