Re: [GENERAL] A real currency type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] A real currency type
Date
Msg-id 4730.1142981709@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] A real currency type  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: [GENERAL] A real currency type
Re: [GENERAL] A real currency type
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Automatically setting work_mem
Next
From: "Luke Lonergan"
Date:
Subject: Re: Automatically setting work_mem