--On Montag, Januar 26, 2009 20:03:41 -0800 Josh Berkus j...@agliodbs.com
wrote:
Jaime, Bernd,
having said that, i don't think that inventing new syntax is the way
to go... a reloption seems better (thinking a little more, it could be
a problem if the user changes the reloptions of an
On Saturday 24 January 2009 02:17:13 Tom Lane wrote:
2. You don't want those rules, so you delete them, leaving you with the
traditional behavior where attempted inserts etc on the view fail.
This was never meant to be supported. If you don't want updates on the rules
to succeed, don't grant
On Tuesday 27 January 2009 05:39:48 Jaime Casanova wrote:
a view should be updatable by default if the query expression is
updatable... what we need is something to make a view READ ONLY even
if it should be updatable by spec...
A view is read-only if you don't grant any write permissions on
On Tuesday 27 January 2009 00:21:08 Jaime Casanova wrote:
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY
--On Dienstag, Januar 27, 2009 14:04:05 +0200 Peter Eisentraut
pete...@gmx.net wrote:
a view should be updatable by default if the query expression is
updatable... what we need is something to make a view READ ONLY even
if it should be updatable by spec...
A view is read-only if you don't
On Tue, Jan 27, 2009 at 8:49 AM, Bernd Helmle maili...@oopsware.de wrote:
--On Dienstag, Januar 27, 2009 14:04:05 +0200 Peter Eisentraut
pete...@gmx.net wrote:
a view should be updatable by default if the query expression is
updatable... what we need is something to make a view READ ONLY even
Robert Haas wrote:
Do we REALLY think there are people out there who are writing INSERT
or UPDATE actions on views on which they haven't installed rules and
counting on the fact that those operations fail for correctness?
Personally, I usually write my code so it inserts into something that
On Tue, Jan 27, 2009 at 10:14 AM, Andrew Dunstan and...@dunslane.net wrote:
Do we REALLY think there are people out there who are writing INSERT
or UPDATE actions on views on which they haven't installed rules and
counting on the fact that those operations fail for correctness?
Personally, I
Peter Eisentraut pete...@gmx.net writes:
On Saturday 24 January 2009 02:17:13 Tom Lane wrote:
2. You don't want those rules, so you delete them, leaving you with the
traditional behavior where attempted inserts etc on the view fail.
This was never meant to be supported. If you don't want
Robert Haas wrote:
On Tue, Jan 27, 2009 at 10:14 AM, Andrew Dunstan and...@dunslane.net wrote:
Do we REALLY think there are people out there who are writing INSERT
or UPDATE actions on views on which they haven't installed rules and
counting on the fact that those operations fail for
On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
If we'd had the SQL-spec behavior from day one, it wouldn't be a
problem, but you can't just blow off the old behavior like that.
It's a potential security hole, since GRANT ALL on a view used to
be de facto the same as GRANT SELECT, if you
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
It's a potential security hole, since GRANT ALL on a view used to
be de facto the same as GRANT SELECT, if you hadn't bothered to
create any rules.
That is a good point. But the only clean solution
On Tue, Jan 27, 2009 at 3:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 27 January 2009 17:19:28 Tom Lane wrote:
It's a potential security hole, since GRANT ALL on a view used to
be de facto the same as GRANT SELECT, if you hadn't bothered to
--On 25. Januar 2009 13:36:35 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [OR REPLACE] [[NOT] UPDATABLE] VIEW ...
? Seems confusing.
Good point. We need a better phrasing to restore
There is another thing that's bothering me, though, which is that the
present approach to dumping rules isn't adequate. Consider the
following scenario:
1. You create a view that the system considers updatable, so
it creates
some automatic rules.
2. You don't want those rules, so you
On Mon, Jan 26, 2009 at 6:48 AM, Zeugswetter Andreas OSB sIT
andreas.zeugswet...@s-itsolutions.at wrote:
Is that why other db's only make views updateable, that are created
WITH CHECK OPTION ? Should we also follow that path ?
no, the standard says that if the query expression is updatable
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the
Bruce Momjian wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you
Jaime Casanova wrote:
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per
Bruce,
yes. we detect that and send a warning saying that there not be any rules
OK, so we are going to need an option to suppress that warning, even
without the problems of upgrades and customization.
Per my response earlier, I think we really logically need an error if
the user specifies
On Mon, Jan 26, 2009 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
Bruce,
yes. we detect that and send a warning saying that there not be any rules
OK, so we are going to need an option to suppress that warning, even
without the problems of upgrades and customization.
Per my response
Jaime, Bernd,
having said that, i don't think that inventing new syntax is the way
to go... a reloption seems better (thinking a little more, it could be
a problem if the user changes the reloptions of an already created
view)
There's also the issue with backup/restore: we need some kind of
On Sat, Jan 24, 2009 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that we probably want the rules to show up automatically during
an upgrade from an older version
I'm really not convinced by that. Is it required by the standard? It's
really far from being compliant with the principle
--On Sonntag, Januar 25, 2009 09:41:14 +0100 Guillaume Smet
guillaume.s...@gmail.com wrote:
I think that we probably want the rules to show up automatically during
an upgrade from an older version
I'm really not convinced by that. Is it required by the standard? It's
really far from being
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian br...@momjian.us wrote:
Well, also consider 8.3 was released in February, so we had 9 months of
development before the last commit-fest started.
Yes - that was good. But what will happen for 8.5?
Also, one thing we have always known is that
Robert Haas wrote:
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian br...@momjian.us wrote:
Well, also consider 8.3 was released in February, so we had 9 months of
development before the last commit-fest started.
Yes - that was good. But what will happen for 8.5?
Probably the same.
--On 24. Januar 2009 20:47:20 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
What i'm missing is some notion about CHECK OPTION. We
surely want to support that in way.
Feel free to insist on that, if you want to make dead certain that
updatable views
Yeah... I'm not sure what to do about that, but as Tom pointed out,
it has the disadvantage that all of these massive changes are getting
put into the tree just before we start beta.
Well, it is less a problem than in previous releases, so things are
getting better.
Well, that is good.
I
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle maili...@oopsware.de wrote:
I didn't find such a notion in the standard. A view is automatically
updatable if it meets the criteria of updatability). If you don't want your
view writable, you have to GRANT the necessary ACLs.
Perhaps I'm a bit old
Bernd Helmle maili...@oopsware.de writes:
I originally had the idea of a GUC which controls wether automatic rules
will be generated or not. But I abonded this idea, since this has some kind
of parametrized SQL standard functionality.
We have GUCs like that already, for exactly the same
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
I originally had the idea of a GUC which controls wether automatic rules
will be generated or not. But I abonded this idea, since this has some kind
of parametrized SQL standard functionality.
We have GUCs like that already,
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan and...@dunslane.net
wrote:
Maybe something like CREATE VIEW WITHOUT UPDATE;
I actually like the idea of being able to turn update on and off for a
view.
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer
2009/1/25 Bernd Helmle maili...@oopsware.de:
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan and...@dunslane.net
wrote:
Maybe something like CREATE VIEW WITHOUT UPDATE;
I actually like the idea of being able to turn update on and off for a
view.
Or what about
CREATE [OR
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [OR REPLACE] [[NOT]
Tom Lane escribió:
The main question in my mind is whether we should have a turn-off
feature that is global (GUC) or per-view (reloption). One difficulty
with a reloption is that there's no way to set it on a view until after
you've done CREATE VIEW, whereupon it's too late --- the auto
On Sun, Jan 25, 2009 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This would all be a little easier to accomplish if the behavior were
made to be implicit in the rewriter (ie, rewrite instead of throwing a
no rule error), since then there is no persistent state that a GUC or
reloption
--On 23. Januar 2009 21:18:19 -0500 Robert Haas robertmh...@gmail.com
wrote:
In the future, I think we should have an expectation that resubmits
within the same CommitFest should happen within a week, and that if no
revision is forthcoming within two weeks the patch is declared dead
(and
I wrote:
... It seems to me that the rule engine
has probably got all the infrastructure needed to convert the query the
way we'd like, we just don't have a suitable API to tell it to do that.
I have in mind a couple of quite different approaches to this, and wanted
to solicit some feedback
Tom Lane t...@sss.pgh.pa.us writes:
ON UPDATE DO INSTEAD SUBSTITUTE base_table [ (base_column_name, ...) ]
[ WHERE ... ]
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
What would happen with these if the view is
--On Samstag, Januar 24, 2009 14:17:58 -0500 Tom Lane t...@sss.pgh.pa.us
wrote:
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
and the rewriter would interpret this appropriately. You'd end up with
essentially the same
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
ON UPDATE DO INSTEAD SUBSTITUTE base_table [ (base_column_name, ...) ]
[ WHERE ... ]
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
What
Bernd Helmle maili...@oopsware.de writes:
What i'm missing is some notion about CHECK OPTION. We
surely want to support that in way.
Feel free to insist on that, if you want to make dead certain that
updatable views don't make it into 8.4 ;-)
My recollection of the discussion two years ago is
You're suggestion doesn't help with the problem that (like Joshua already
mentioned) core developers are too busy with reviewing stuff during the
CommitFest. Because of this it's really hard to get the necessary time of
somebody who is able to evaluate the architecture of a new feature and
Robert Haas wrote:
On the other hand, it's easy to draw a line from the lax criteria for
resubmitting patches to the length of this CommitFest. It now appears
that this CommitFest will be something like 3.5 months long and that
the next one will not occur before May. That means we're
On Fri, Jan 23, 2009 at 7:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that we probably want the rules to show up automatically during
an upgrade from an older version, but it does not follow that they
should come back after being intentionally removed from an 8.4
installation.
[...]
pet...@postgresql.org (Peter Eisentraut) writes:
Automatic view update rules
This patch is still a few bricks shy of a load ... within a few moments
of starting to look at it I'd noticed two different failure conditions
regression=# \d box_tbl
Table public.box_tbl
Column | Type | Modifiers
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied. It's probably
fixable with a week or so's work, but do we want to be expending that
kind of effort on it at this stage of the release cycle?
Uh well, i'd be
Bernd Helmle wrote:
If i understand you correctly we have the choice between
a) revert this patch, fix all remaining issues which will likely postpone
this for 8.5
b) don't revert, but try to fix the issues currently existing in HEAD.
c) revert and expect an updated patch to apply very
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review comments would have been made
earlier in the CommitFest.
[ shrug... ] I've been
On Fri, 2009-01-23 at 17:32 -0500, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review comments would have been
Bernd,
To be honest: I'm disappointed. If it tooks only a few steps to identify
those (obviously important) issues, i get the opinion that there's very
few motivating interest in this functionality (And yes, i'm annoyed
about myself to not consider those operator issues).
Well, that *is*
On Fri, Jan 23, 2009 at 5:52 PM, Josh Berkus j...@agliodbs.com wrote:
Bernd,
If it makes you feel any better, I certainly didn't think of the operator
issue, and neither did Robert.
to be honest, i feel like that was commented in the last (or the last
before the last) release cycle well this
--On 23. Januar 2009 17:32:55 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
In short, I don't feel that this was ready to be applied.
Uh well, i'd be happier if such review
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps the right answer is to invent some new rule syntax to redirect
inserts/updates/deletes, say something like
on update to foo do instead redirect to bar
and then put some logic that's not so much different from
--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova
jcasa...@systemguards.com.ec wrote:
to be honest, i feel like that was commented in the last (or the last
before the last) release cycle well this patch originally appears.
I know that i've changed something in the operator lookup code
--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova
jcasa...@systemguards.com.ec wrote:
and what about default values? if we redirect we will have to use the
table's default (something i like) and AFAIU we won't have the ability
to change it for the view at least not without manually create
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps the right answer is to invent some new rule syntax to redirect
inserts/updates/deletes, say something like
on update to foo do instead redirect to bar
and what
Uh well, i'd be happier if such review comments would have been made earlier
in the CommitFest.
Well, as one of original reviewers of this patch, I feel a little bad
that I didn't consider these issues - the rules looked messy to me,
but I didn't consider that the whole approach might be wrong.
59 matches
Mail list logo
