On Wed, Jan 21, 2009 at 11:09 AM, Peter Eisentraut 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
src/backend/rewrite/viewUpdate.c:form_where_for_up
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 Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
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.
checkTree() will r
Bernd Helmle wrote:
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
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 fe
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut
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 was that it wou
Peter Eisentraut 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 principle. We'll
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 regres
--On Montag, Januar 12, 2009 14:48:46 +0200 Peter Eisentraut
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
viewUpdate.o view
Bernd Helmle wrote:
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
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 a
--On Freitag, Januar 09, 2009 17:53:31 +0100 Bernd Helmle
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 and so the new files
--On Freitag, Januar 09, 2009 13:20:57 +0100 Bernd Helmle
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 in
a current view (an
--On Sonntag, Dezember 28, 2008 15:29:58 +0100 Bernd Helmle
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 columns
(extract
> On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle wrote:
>
> i would say check for negative attnums and deny that view to be
> updateable because of SQL92 says in 11.19 syntax
> rule 6:
> """
> 6) If the is updatable, then the viewed table
> is
> an updatable table. Otherwise
On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle 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).
>
i would say
> On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle
> wrote:
>> --On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
>> wrote:
>>
>> Okay, i've finally managed to create an updated version with (hopefully)
>> all
>> issues mentioned by Robert adressed.
>>
>
> Hi Bernd,
>
> 1) i found a crash
>> 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
On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle wrote:
> --On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
> wrote:
>
> Okay, i've finally managed to create an updated version with (hopefully) all
> issues mentioned by Robert adressed.
>
Hi Bernd,
1) i found a crash type bug, try this:
--On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
wrote:
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
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'.
Okay, i've f
--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 m
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:
http://www.postgresql.org/ma
>> - "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 o
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.
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 read-
--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
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 f
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 ba
27 matches
Mail list logo
