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@xxxxxxxxxxxxxxxxxx> wrote in message news:200605252155.52906.lists@xxxxxxxxxxxxxxxxxxxxx > 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 >
