Re: [GENERAL] A real currency type

From: August Zajonc <augustz(at)augustz(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] A real currency type
Date: 2006-03-24 16:54:54
Message-ID: e018aa$159e$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Martijn van Oosterhout wrote:
> On Tue, Mar 21, 2006 at 03:59:31PM -0500, Andrew Dunstan wrote:
>>> I think such types would be better implemented as some sort of
>>> structured type, possibly with constructors and methods and all the
>>> other stuff that SQL talks about. We don't have all of that yet --
>>> maybe we don't need all of it immediately -- but before we start
>>> endorsing many of these types I'd like to see some consideration given
>>> to this issue.
>> Yeah, looks interesting but let's find the wrinkles. I was wondering if
>> it might have relevance to what I wanted to do with enumeration types,
>> i.e. we would tag each one with its particular enumeration id.
>
> I have considered making enumeration types with this. It would probably
> work but kind of overkill. The main problem being that this code is
> seriously aimed at creating new types that you intend to do operations
> on, create operators for. An enumeration is just that, an enumeration.
>
>> I also don't like the idea of it being done with user tables - if this
>> is core material then the tags should go in the catalog, ISTM.
>
> But the user is providing the list of tags when creating the type.
> Unless you are proposing copying the tag table to the catalog when the
> type is created? You can't store all the tags for all tagged types in
> one tag table either. At least, that wasn't what I was envisiging. See
> the currency type where the tag-table also stores the format string for
> output. No other tagged type is going to need that information.
>
> SQL types with constructors and methods might provide this also, I
> don't know. My purpose with this was allowing people to simply create
> new types with specific behaviour without writing functions in C. Right
> now type input/output functions cannot be written in anything other
> than C. Here are a few C functions that handle these new types in a
> generic way and user can write little pl/pgsql wrappers to customise
> the output.
>
> Have a ncie day,
>
Martin,

This would be extremely useful to have.

For example, if I store currencies tagged properly, I could do a select
and multiply the currency tag by the factor associated with that tag.
This would allow easily quoting financials in a standard currency, but
protect against type mismatches presumably at the database level (USD +
AUD fails).

Either way, it should be easy to add tags (ie, INSERT or similar) or get
a list of them (SELECT * from somewhere where type = "currency"). I'm
sure this later will be the case system catalog or not.

- August

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Julie Robinson 2006-03-24 16:58:57 Hibernate Query Question - Get most recent unique rows
Previous Message Scott Marlowe 2006-03-24 16:32:42 Re: Advantages of PostgreSQL over MySQL 5.0

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-03-24 17:10:00 Re: [GENERAL] A real currency type
Previous Message Tom Lane 2006-03-24 15:12:27 Re: Nightly builds