Re: multi-row check constraints?

From: "Angva" <angvaw(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: multi-row check constraints?
Date: 2007-03-27 22:10:39
Message-ID: 1175033439.629696.162230@o5g2000hsb.googlegroups.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mar 22, 8:09 pm, p(dot)(dot)(dot)(at)j-davis(dot)com (Jeff Davis) wrote:
> On Tue, 2007-03-20 at 13:21 -0700, Angva wrote:
>
> Your Oracle solution is interesting, and can indeed be implemented in
> PostgreSQL in exactly the same way. Look at materialized views here:
>
> http://www.varlena.com/varlena/GeneralBits/Tidbits/matviews.html
>
> Another way to do it without using an entire materialized view is to
> obtain a row level lock on the ID using SELECT ... WHERE id=123 FOR
> UPDATE. To do this you need to have a table that contains all the IDs
> and where id has a unique index to prevent race conditions when adding
> new IDs.
>
> What are you trying to do exactly? Why does the table have no primary
> key?

Thanks for that info. The materialized view functions look a bit
unwieldy for this one purpose...Your other idea might be simpler to
implement.

What I'm trying to accomplish...I'm dealing with financial accounts,
each of which has a purchase limit of $x, and one or more sub-
accounts. Each sub-account is allocated a percentage of this limit. So
account A could have sub-accounts 1, 2 and 3, with 50%, 30% and 20%
respectively allocated. Or there could be just one sub-account with
exactly 100%.

The "real" table actually does have a primary key - I was using a
simplified example to make my point.

Thanks for your input,
Mark

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Qiao Yang 2007-03-27 22:35:06 Postgres 8.2.3 or 8.1.8?
Previous Message Angva 2007-03-27 21:38:07 Re: multi-row check constraints?