Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
Sure, but it is inside the rule that has 'where x is not null and y is
not null' on it as a qualifier, so
with my test example it should just never get executed in the first place.
You're confusing rules with triggers. The INSERT *
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Sure, but it is inside the rule that has 'where x is not null and y is
> not null' on it as a qualifier, so
> with my test example it should just never get executed in the first place.
You're confusing rules with triggers. The INSERT *will* get executed
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
Something like
insert into test
select null,null union select 1,2 where false
has the same problem... and it doesn't refer to any relations.
But that's parsed as
insert into test
(select null,null) union (select 1,2 where false)
so
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Something like
> insert into test
> select null,null union select 1,2 where false
> has the same problem... and it doesn't refer to any relations.
But that's parsed as
insert into test
(select null,null) union (select 1,2 where false)
so I'd expect it t
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
create rule insert_test as on insert to test_view where new.x is not
null and new.y is not null do instead
(
insert into test
select new.* union
select new.*;
);
Mmm. In CVS tip that throws
ERROR: UNION/INTERSECT/EXCEPT mem
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> create rule insert_test as on insert to test_view where new.x is not
> null and new.y is not null do instead
> (
>insert into test
>select new.* union
>select new.*;
> );
Mmm. In CVS tip that throws
ERROR: UNION/INTERSECT/EXCEPT member sta
Aha!
I got it.
This generates the 'cannot insert null...' error:
create table test (x int not null, y int not null);
create table test_reject (x int, y int, reason text);
create view test_view as select * from test;
create rule reject_x as on insert to test_view where new.x is null do
instead in
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> But what the hell is my problem then??? I swear, I do insert into the
> view there :-)
> It's a really huge view, looking at a whole bunch of different tables...
> I'd hate having to post the whole thing...
All I can guess is a bug (or pilot error) that
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
Ok... What's wrong with this one then
testdb=# insert into test values (null, null);
ERROR: ExecInsert: Fail to add null value in not null attribute x
Try inserting into test_view ...
regards, tom lane
Damn!
Sorry abo
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Ok... What's wrong with this one then
> testdb=# insert into test values (null, null);
> ERROR: ExecInsert: Fail to add null value in not null attribute x
Try inserting into test_view ...
regards, tom lane
-
Oh, I see what you're on about. Sorry, a "DO INSTEAD NOTHING" only
suppresses the original command, it does not suppress other rules.
I think what you want is to make the insert_test rule conditional
on x being not null.
regards, tom lane
Ok... What's wrong with this one then (three rules
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
The problem is that in the 'real life' situation the condition is a lot
more complicated than this simple is null test... I hate having to
duplicate it, and I hate even more having to evaluate it twice on every
insert :-(
Why eval
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> The problem is that in the 'real life' situation the condition is a lot
> more complicated than this simple is null test... I hate having to
> duplicate it, and I hate even more having to evaluate it twice on every
> insert :-(
Why evaluate it twice?
Tom Lane wrote:
Oh, I see what you're on about. Sorry, a "DO INSTEAD NOTHING" only
suppresses the original command, it does not suppress other rules.
I think what you want is to make the insert_test rule conditional
on x being not null.
Yeah... that's what I was afraid of :-(
The problem is
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> I know... That was a typo in my sql :-)
> But for this example it doesn't matter - that view/table is only needed
> to illustrate the rules behaviour on insert.
Oh, I see what you're on about. Sorry, a "DO INSTEAD NOTHING" only
suppresses the original c
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> Secondly, even if it has to be this way, it looks like the help entry is
> out of date...
No, but your psql evidently is. I get
regression=# \h drop rule
Command: DROP RULE
Description: remove a rewrite rule
Syntax:
DROP RULE name ON relation [ CAS
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
testdb=# create table test_view as select * from test;
SELECT
That is not a view, it's only a static copy of the original table.
regards, tom lane
I know... That was a typo in my sql :-)
But for this example it doesn't matter
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> testdb=# create table test_view as select * from test;
> SELECT
That is not a view, it's only a static copy of the original table.
regards, tom lane
---(end of broadcast)---
TIP 9:
... and here is another bug I ran into while trying to investigate my
earlier problem with views a little more:
testdb=# drop rule skip_test;
ERROR: parser: parse error at or near ";" at character 20
testdb=# \h drop rule
Command: DROP RULE
Description: remove a rewrite rule
Syntax:
DROP RUL
Here is a problem a ran into:
testdb=# create table test (x int);
CREATE TABLE
testdb=# create table test_view as select * from test;
SELECT
testdb=# create rule insert_test as on insert to test_view do instead
insert into test values (new.*);
CREATE RULE
testdb=# create rule skip_test as on inse
Hi All
I am running on
Solaris 9 - Jumbo Kernel Patch 06 - Full Distribution (sparc)
GNU gcc 3.3
GNU make 3.8
GNU readline 4.3
The correct settings in /etc/system are made and the server restarted (I
have 2 other instances of postgresql running - 7.1 on a Solaris 8 server)
The install of versio
21 matches
Mail list logo
