You are apparently dealing with the downside of co-mingling your clients
data... maybe you should seriously consider revising your approach and
giving each client either separate databases or separate schema's within a
given database --
This is why co-mingling should be avoided...
I'd push for the former -- that way -- you can use a template database
instead of hoping that all of your filters, rules, views, etc are
accurate...
"Benjamin Smith" <lists@benjamindsmith.com> wrote in message
news:200605252155.52906.lists@benjamindsmith.com...
> We have a growing ASP-hosted application built on PHP/Postgres 8.1, and
> are
> getting requests from clients to manipulate the databases more directly.
> However, the structure of our databases prevents this from happening
> readily.
>
> Assume I have two tables configured thusly:
>
> create table customers (
> id serial unique not null,
> name varchar not null
> );
>
> create table widgets (
> customers_id integer not null references customers(id),
> name varchar not null,
> value real not null default 0
> );
>
> insert into customers (name) values ('Bob');
> insert into customers (name) values ('Jane');
> insert into widgets (customers_id, name, value) VALUES (1, 'Foo', 100);
> insert into widgets (customers_id, name, value) VALUES (1, 'Bar', 50);
> insert into widgets (customers_id, name, value) VALUES (2, 'Bleeb', 500);
>
> This leaves us with two customers, Bob who has two widgets worth $150, and
> Jane with one widget worth $500.
>
> How can I set up a user so that Bob can update his records, without
> letting
> Bob update Jane's records? Is it possible, say with a view or some other
> intermediate data type?
>
> Thanks,
>
> -Ben
> --
> "The best way to predict the future is to invent it."
> - XEROX PARC slogan, circa 1978
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>