Here is my latest reworked patch that fixes all outstanding issues.
view_update-petere-20090121.patch.bz2
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jan 21, 2009 at 11:09 AM, Peter Eisentraut pete...@gmx.net wrote:
Here is my latest reworked patch that fixes all outstanding issues.
1) there's a regression failure, it's just a message that changes...
attached regression.diffs
2) this comment on
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net wrote:
* It is not clear how automatic rules and manual DO ALSO rules should
interact. A manual DO ALSO rule will currently clear out an automatic
INSTEAD rule, which I find to be illogical.
My intentional feeling
Bernd Helmle wrote:
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net wrote:
* It is not clear how automatic rules and manual DO ALSO rules should
interact. A manual DO ALSO rule will currently clear out an automatic
INSTEAD rule, which I find to be illogical.
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
pete...@gmx.net wrote:
Here is my updated patch based on yours.
Outstanding issues, as far as I can see, are:
Critical:
* Updatability check must reject views where the select list references
the same column more than once.
Here is my updated patch based on yours.
Outstanding issues, as far as I can see, are:
Critical:
* Updatability check must reject views where the select list references
the same column more than once.
* Various scenarios of REPLACE VIEW misbehave. I have marked these as
FIXME in the
Peter Eisentraut pete...@gmx.net writes:
CASE will be quite bad for optimization, and then you might as well go
with IS DISTINCT FROM, which is just as bad but simpler.
Definitely avoid CASE if you can. Although the planner currently knows
nothing about IS DISTINCT FROM, that's fixable in
Bernd Helmle wrote:
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
maili...@oopsware.de wrote:
I've decided to check updatability of all involved views during view
creation. Please find attached a new version with all other open issues
adressed.
Oops, forgot to track some files
--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut
pete...@gmx.net wrote:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-g -I../../../src/include -I/sw/include/libxml2 -I/sw/include -c -o
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
maili...@oopsware.de wrote:
I've decided to check updatability of all involved views during view
creation. Please find attached a new version with all other open issues
adressed.
Oops, forgot to track some files in my new git branch
--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle
be...@oopsware.de wrote:
maybe the better solution is to not allow such a view to be updatable
Yes, it seems we have to check for target lists having negative attnums in
checkTree(). Another solution would be to simply ignore those
--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle
maili...@oopsware.de wrote:
That means, View1 consists of View2 and so on. What happens now if
someone is going to change View3, so that it's not updatable anymore?
What the patch actually does is, scanning all relations/views involved
On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle be...@oopsware.de wrote:
i would say check for negative attnums and deny that view to be
updateable because of SQL92 says in 11.19 view definition syntax
rule 6:
6) If the query expression is updatable, then the viewed table
is
2) Another less important bug, the WITH CHECK OPTION is accepted even
when that functionality is not implemented.
updatable_views=# create or replace view v2 as select * from foo where
id 10 with check option;
NOTICE: CREATE VIEW will create implicit INSERT/UPDATE/DELETE rules
CREATE VIEW
On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle maili...@oopsware.de
wrote:
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
Okay, i've finally managed to create an updated version with (hopefully)
all
issues mentioned by Robert adressed.
Hi Bernd,
On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle be...@oopsware.de wrote:
Yes, it seems we have to check for target lists having negative attnums in
checkTree(). Another solution would be to simply ignore those columns
(extract them from the target list and include all updatable columns
only).
On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle maili...@oopsware.de wrote:
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
Okay, i've finally managed to create an updated version with (hopefully) all
issues mentioned by Robert adressed.
Hi Bernd,
1)
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
maili...@oopsware.de wrote:
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
robertmh...@gmail.com wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the status to 'waiting on author'.
--
Thanks
Bernd
--
Sent via pgsql-hackers
Bernd,
Do you intend to submit an updated version of this patch for this commitfest?
If not, I will move this to Returned with feedback.
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
--On Dienstag, November 11, 2008 23:06:08 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Thanks for your look at this. Unfortunately i was travelling the last 2
days, so i didn't have time to reply earlier, sorry for that.
I haven't done a full review of this patch, but here are some thoughts
On Nov 11, 2008, at 10:06 PM, Robert Haas wrote:
- Should this be an optional behavior? What if I don't WANT my view
to be updateable?
That seems like a deal-breaker to me... many users could easily be
depending on views not being updateable. Views are generally always
thought of as
Decibel! [EMAIL PROTECTED] writes:
That seems like a deal-breaker to me... many users could easily be
depending on views not being updateable. Views are generally always
thought of as read-only, so you should need to explicitly mark a view
as being updateable/insertable/deleteable.
The
- make check fails 16 of 118 tests for me with this patch applied.
Most of them are caused by additional NOTICE messages or unexpected
additional rules in the rewriter regression tests. I don't see anything
critical here.
Possible; in that case you should patch the expected regression output
I haven't done a full review of this patch, but here are some thoughts
based on a quick read-through:
- make check fails 16 of 118 tests for me with this patch applied.
- There are some unnecessary hunks in this diff. For example, some of
the gram.y changes appear to move curly braces around,
--On Donnerstag, Oktober 30, 2008 21:24:08 +0100 Bernd Helmle
[EMAIL PROTECTED] wrote:
Note that i'm still working on this (for example, RETURNING is missing
yet), As always, discussion welcome ;)
This new version implements RETURNING support for implicit view update
rules and does some
Please find attached my current patch for automatic view update rules.
This is a stripped down version of my former patch discussed before 8.3
without CHECK OPTION support and less invasive changes to the rewriter
itself.
I'm currently cleaning up the code with all occurences of multiple
27 matches
Mail list logo
