Re: [GENERAL] A real currency type

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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