Re: [GENERAL] A real currency type

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] A real currency type
Дата
Msg-id 4730.1142981709@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] A real currency type  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: [GENERAL] A real currency type  (Martijn van Oosterhout <kleptog@svana.org>)
Re: [GENERAL] A real currency type  ("Andrew Dunstan" <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Automatically setting work_mem
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Automatically setting work_mem