From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: [PATCHES] Updatable views |
Date: | 2006-09-01 15:41:16 |
Message-ID: | 5155.1157125276@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> What we can do is to restrict view updates that involves a volatile function
> completely. As soon as the rewriter wants to apply an implicit system rule
> to a current query which holds volatile functions, we could treat this as
> an error.
So in other words, views on serial columns don't work? I don't think
that's going to be acceptable.
> In order you want to do a CASCADED CHECK OPTION,
> you need to collect all expressions out of underlying relations and rewrite
> them to match
> the table you are selecting...that looks like a very expensive operation.
Not really worse than what the rewriter is doing already --- in fact,
I think it's isomorphic to what would happen to the rule qual
expressions in your existing patch.
> So we need to stall this idea unless we have something workable in
> this area. So what's the plan for 8.2? Should we reject updatable
> views completely or is there some interest to apply this without CHECK
> OPTION?
I'm about to propose that we should try to go beta next week (see
forthcoming message). If you can strip down your patch to avoid the
multi-eval problems in the next couple of days, I'm still willing to
consider it, but at the moment I'm assuming that it needs to be held
for 8.3.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-09-01 15:49:17 | Re: Sort performance |
Previous Message | Alvaro Herrera | 2006-09-01 15:34:49 | Re: [PATCHES] Updatable views |