From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-general(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>, ken(at)sunward(dot)org |
Subject: | Re: Why does an ON SELECT rule have to be named "_RETURN"? |
Date: | 2006-02-16 15:41:16 |
Message-ID: | 28448.1140104476@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Thu, Feb 16, 2006 at 07:28:20AM -0500, Robert Treat wrote:
>> One problem is the only way for a client tool to work generically in prov=
> ding
>> data entry forms would be to provide entry for all columns, which would b=
> reak
>> in all but the most trivial of cases. Last time we discussed this for
>> phppgadmin, the general opinion was it wasn't worth trying to work around=
>
>> postgresql core's deficiency. Once the core postgresql server supports
>> updatable views in proper, I'd imagine this would get done.
> In the general case, if there are any INSERT/UPDATE/DELETE RULEs on a
> view, there is no way for the client to determine what the effect will
> be except in the simplest of cases, letting the user specify seems the
> best bet.
I agree that this decision on phppgadmin's part seems unsupportable.
Either there is an ON UPDATE rule on a view or there isn't --- it is not
phppgadmin's job to determine what cases that rule supports. Try to do
the update, and complain if it fails, is all that is required from a
client-side tool.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-16 15:48:41 | Re: A question about Vacuum analyze |
Previous Message | Chad | 2006-02-16 15:41:09 | How do I use the backend APIs |