On Tue, Jan 27, 2009 at 3:36 PM, Tom Lane wrote:
> Peter Eisentraut 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.
>
>> T
Peter Eisentraut 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 would be
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 yo
Robert Haas wrote:
On Tue, Jan 27, 2009 at 10:14 AM, Andrew Dunstan 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,
Peter Eisentraut 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 updates on th
On Tue, Jan 27, 2009 at 10:14 AM, Andrew Dunstan 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 wr
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
is
On Tue, Jan 27, 2009 at 8:49 AM, Bernd Helmle wrote:
> --On Dienstag, Januar 27, 2009 14:04:05 +0200 Peter Eisentraut
> 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 updata
--On Dienstag, Januar 27, 2009 14:04:05 +0200 Peter Eisentraut
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 pe
On Tuesday 27 January 2009 00:21:08 Jaime Casanova wrote:
> On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bernd Helmle writes:
> >> > Or what about
> >> > CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
> >> > This looks closer to TEMP|TEMPORARY VIEW, which we already
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 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 Montag, Januar 26, 2009 20:03:41 -0800 Josh Berkus
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 already created
view)
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 sy
On Mon, Jan 26, 2009 at 8:47 PM, Josh Berkus 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 earlier
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
Jaime Casanova wrote:
> On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bernd Helmle writes:
> >> > Or what about
> >> > CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
> >> > This looks closer to TEMP|TEMPORARY VIEW, which we already have.
> >>
> >> But per spec, UPDATA
Bruce Momjian wrote:
Tom Lane wrote:
Bernd Helmle 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 [O
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bernd Helmle 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,
Tom Lane wrote:
> Bernd Helmle 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 REP
On Mon, Jan 26, 2009 at 6:48 AM, Zeugswetter Andreas OSB sIT
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 the
view is updatable
--
At
> 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
--On 25. Januar 2009 13:36:35 -0500 Tom Lane 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 the old behavior, m
On Sun, Jan 25, 2009 at 11:47 AM, Tom Lane 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 would have to tr
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 r
Bernd Helmle 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] UPDATABLE] VIEW .
2009/1/25 Bernd Helmle :
>
>
> --On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan
> 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
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan
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 to TEMP|TEMPORARY VIE
Tom Lane wrote:
Bernd Helmle 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 sa
Bernd Helmle 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 reason: backwards
co
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle 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 school on this one
>> 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 g
--On 24. Januar 2009 20:47:20 -0500 Tom Lane wrote:
Bernd Helmle 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 ;-)
Of course, i'
Robert Haas wrote:
> On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian 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.
> > Also, one t
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian 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 many of the compl
--On Sonntag, Januar 25, 2009 09:41:14 +0100 Guillaume Smet
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 principl
On Sat, Jan 24, 2009 at 1:17 AM, Tom Lane 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 of least surprise
On Fri, Jan 23, 2009 at 7:17 PM, Tom Lane 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.
>
[...]
>
> We could im
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 esse
> 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
Bernd Helmle 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 that we concluded
Gregory Stark writes:
> Tom Lane 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
--On Samstag, Januar 24, 2009 14:17:58 -0500 Tom Lane
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 results as with the ot
Tom Lane 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 defined with "S
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
--On 23. Januar 2009 21:18:19 -0500 Robert Haas
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 the submitter can add it
> 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
Jaime Casanova writes:
> On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane 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 about default values?
I don't see the is
--On 23. Januar 2009 18:07:38 -0500 Jaime Casanova
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 a new
DO INSTEAD rule (someth
--On 23. Januar 2009 18:02:55 -0500 Jaime Casanova
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 regarding
some discussions las
On Fri, Jan 23, 2009 at 5:32 PM, Tom Lane 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 what you'
--On 23. Januar 2009 17:32:55 -0500 Tom Lane wrote:
Bernd Helmle writes:
--On 23. Januar 2009 13:28:27 -0500 Tom Lane 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.
[ shr
On Fri, Jan 23, 2009 at 5:52 PM, Josh Berkus 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 patch origin
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* the
On Fri, 2009-01-23 at 17:32 -0500, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 23. Januar 2009 13:28:27 -0500 Tom Lane 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 CommitFe
Bernd Helmle writes:
> --On 23. Januar 2009 13:28:27 -0500 Tom Lane 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 busting my butt since 1 November t
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
--On 23. Januar 2009 13:28:27 -0500 Tom Lane 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 happier if such revie
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 | Modifier
59 matches
Mail list logo
