> However, the rule system already
> adds the CTID TE to the query tree and it looks to me this can be extended to
> provide
> the requested behavior. The way the rewriter handles it's query
> qualifications would have to
> be redesigned as well, i think, but i don't know what can of worms there
On Tue, 19 Dec 2006 07:22:36 -0800 (PST), Richard Broersma Jr <[EMAIL
PROTECTED]> wrote:
>> Once you update one side of the join with a
>> different join key value, the join row in question no longer exists in
>> the view ... so the second update doesn't find a row to update. This
>> has noth
> At no point did you show us details, but I suppose that this rule is
> relying on a join view?
Yes, the view is a join between two tables as a test case. I provided the
details of my test case
below. However, I could see the use of joining as many as four tables in an
updatable view.
> On
Richard Broersma Jr <[EMAIL PROTECTED]> writes:
> My concern regarding the rule system is not related to the incorrect
> update count but the fact that my update statement was suppose to
> change BOTH name AND dresssize. However, as you see only the name was
> changed, dresssize remains unchanged.
> > postgres=# update vwife
> >set name = 'Katheryn',
> >dresssize = 12
> >where (id,name,dresssize)=(2,'katie',11);
> > UPDATE 0
> > postgres=# select * from vwife;
> > id | name | dresssize
> > +--+---
> > 2 | Katheryn |11
> The difference here is that by passing the values into a function, it
> creates a copy of the value, meaning it won't change due to an UPDATE.
> The only negative of using a function is that the number of affected
> tuples will always be zero.
The function and rule does indeed work from the psql
On Mon, 2006-12-18 at 17:09 -0800, Richard Broersma Jr wrote:
> > Actually, I am seeing some unexpected behavior, or rather behavior that
> > I wouldn't expect. After the first UPDATE in the rule, NEW and OLD are
> > gone.
>
> I guess the end-result behaviour I am looking for (as you mentioned) is
> Actually, I am seeing some unexpected behavior, or rather behavior that
> I wouldn't expect. After the first UPDATE in the rule, NEW and OLD are
> gone.
I guess the end-result behaviour I am looking for (as you mentioned) is having
an update-able view
behave exactly as if it were a table in reg
On Mon, 2006-12-18 at 15:30 -0800, Richard Broersma Jr wrote:
> > > postgres=# update vwife
> > >set name = 'Katheryn',
> > >dresssize = 12
> > >where (id,name,dresssize)=(2,'katie',11);
> >
> > In "UPDATE #", # is the result of the libpq function PQcmdTup
> What I was trying to explain is that all of your statements *are*
> succeeding. A WHERE clause in an UPDATE may match zero or more rows. The
> second UPDATE in your rule matches zero rows.
I see, that makes sense. I guess that my confussion was that update 0 was
not the same as success.
> You
> > postgres=# update vwife
> >set name = 'Katheryn',
> >dresssize = 12
> >where (id,name,dresssize)=(2,'katie',11);
>
> In "UPDATE #", # is the result of the libpq function PQcmdTuples(), and
> it refers to the number of tuples affected by the last comman
On Mon, 2006-12-18 at 15:06 -0800, Richard Broersma Jr wrote:
> > None of A, C, I, or D say that you need to report a truthful update
> > count.
> >
> > The fact that the update count is wrong with updatable views is a known
> > deficiency.
>
> I see. However, my my case I would like all of th
> None of A, C, I, or D say that you need to report a truthful update
> count.
>
> The fact that the update count is wrong with updatable views is a known
> deficiency.
I see. However, my my case I would like all of the sql statments in the rule
to succeed and if
they don't I would want none
On Mon, 2006-12-18 at 13:42 -0800, Richard Broersma Jr wrote:
> > > Would there be any interest in making rules with multiple sql statements
> > > acid compliant?
> > They are.
>
> postgres=# update vwife
>set name = 'Katheryn',
>dresssize = 12
>where (i
Richard Broersma Jr wrote:
> postgres=# update vwife
>set name = 'Katheryn',
>dresssize = 12
>where (id,name,dresssize)=(2,'katie',11);
> UPDATE 0
>
> postgres=# select * from vwife;
> id | name | dresssize
> +--+---
> 3 | dodie
> > Would there be any interest in making rules with multiple sql statements
> > acid compliant?
> They are.
Am I missing something then, becuase I have cases where it is possible to get
partial updates from
the multi-sql statement rule? I suppose that my understanding of "ACID"
actually mean
On Mon, 2006-12-18 at 13:20 -0800, Richard Broersma Jr wrote:
> I didn't see this on the to-do list.
>
> Would there be any interest in making rules with multiple sql statements acid
> compliant?
>
They are.
Regards,
Jeff Davis
---(end of broadcast)---
I didn't see this on the to-do list.
Would there be any interest in making rules with multiple sql statements acid
compliant?
Regards,
Richard Broersma Jr.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
18 matches
Mail list logo
