Search Postgresql Archives

Re: Why does an ON SELECT rule have to be named "_RETURN"?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2006-02-16 at 10:41, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@xxxxxxxxx> 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.
> 

This is semi-orthogonal, but I'd hoped that with first-class updatable
views we might get some method to determine which columns are actually
updatable, but perhaps this is just wishful thinking? 


Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux