database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-29 22:49:41 +03:00
Code Activity
Files
3145cbc14f2e213697c618db7966b41016c24f06
postgres/doc/TODO.detail/return
Bruce Momjian 8009c27592 Add 'return' file.
2002-08-26 17:40:27 +00:00

1364 lines
64 KiB
Plaintext
Raw Blame History

From pgsql-hackers-owner+M22587@postgresql.org Wed May 8 19:47:28 2002
Return-path: <pgsql-hackers-owner+M22587@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g48NlR416874
for <pgman@candle.pha.pa.us>; Wed, 8 May 2002 19:47:27 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id A5D5F475ED7; Wed, 8 May 2002 19:47:18 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 074664762D2; Wed, 8 May 2002 19:38:42 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 54D9A475F6C
for <pgsql-hackers@postgresql.org>; Wed, 8 May 2002 19:38:32 -0400 (EDT)
Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86])
by postgresql.org (Postfix) with ESMTP id 5ACCD476487
for <pgsql-hackers@postgresql.org>; Wed, 8 May 2002 19:08:19 -0400 (EDT)
Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1])
by localhost.mallet-assembly.org (Postfix) with ESMTP id 8399D12F78C
for <pgsql-hackers@postgresql.org>; Wed, 8 May 2002 19:08:10 -0400 (EDT)
Received: by amanda.mallet-assembly.org (Postfix, from userid 1000)
id 0730F12F685; Wed, 8 May 2002 19:08:02 -0400 (EDT)
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Queries using rules show no rows modified?
From: Michael Alan Dorman <mdorman@debian.org>
Date: 08 May 2002 19:08:01 -0400
Message-ID: <87znzaqlv2.fsf@amanda.mallet-assembly.org>
Lines: 61
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
I'm using 7.2.1 on a Debian system.
If I do an insert or update or delete on a table, postgres tells me
how many rows were affected.
Using the following input to psql, I got the results:
INSERT 0 0
UPDATE 0
DELETE 0
Is this expected? The principle of least suprise suggests to me that
regardless of the query being rewritten, there is some number of
tuples being affected, and it would thus still be appropriate to
return that number.
I realize it's not technically a "bug", since there's no particular
guarantee that someone specified existing records or whatnot, but as
an additional fourth-string check in some web code I put together, I
was checking to see if stuff was returned or updated (since the system
should only being allowing changes to things that exist) as a
heuristic to guard against 1) bugs, and 2) attempts to maliciously
subvert the public interface.
I can find no mention of this issue in the documentation regarding the
rule system. Anyone have any guidance?
Mike.
-----8<-----
drop sequence member_id_seq;
create sequence member_id_seq;
drop table member;
create table member (
id integer not null constraint member_id primary key default nextval('member_id_seq'),
created timestamp not null default now (),
modified timestamp not null default now (),
deleted timestamp default null,
email character varying (128) not null constraint member_email unique,
password character varying (128) not null
);
drop view members;
create view members as select * from member m1 where m1.deleted is null;
drop rule members_delete;
create rule members_delete as on delete to members do instead update member set deleted = current_timestamp;
drop rule members_insert;
create rule members_insert as on insert to members do instead insert into member (email, password) values (new.email, new.password);
drop rule members_update;
create rule members_update as on update to members do instead update member set email = new.email, password = new.password;
insert into members (email, password) values ('mdorman@wombat.org','pinochle');
update members set email='mdorman@lemur.org', password='wombat' where id = 1;
delete from members where id = 1;
----->8-----
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
From pgsql-hackers-owner+M22589@postgresql.org Wed May 8 20:15:34 2002
Return-path: <pgsql-hackers-owner+M22589@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g490FY417439
for <pgman@candle.pha.pa.us>; Wed, 8 May 2002 20:15:34 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id DFD6E4762E1; Wed, 8 May 2002 20:15:21 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 26D52476140; Wed, 8 May 2002 20:15:05 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 86B5947593F
for <pgsql-hackers@postgresql.org>; Wed, 8 May 2002 20:14:51 -0400 (EDT)
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by postgresql.org (Postfix) with SMTP id 2BA754758F6
for <pgsql-hackers@postgresql.org>; Wed, 8 May 2002 20:14:46 -0400 (EDT)
Received: (qmail 25269 invoked from network); 9 May 2002 00:14:48 -0000
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
by sd2.tpf-fw-c.co.jp with SMTP; 9 May 2002 00:14:48 -0000
Received: from tpf.co.jp ([126.0.1.68])
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id JAA09255;
Thu, 9 May 2002 09:14:46 +0900 (JST)
Message-ID: <3CD9BFCC.268A52E0@tpf.co.jp>
Date: Thu, 09 May 2002 09:16:12 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: Michael Alan Dorman <mdorman@debian.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Michael Alan Dorman wrote:
>
> I'm using 7.2.1 on a Debian system.
>
> If I do an insert or update or delete on a table, postgres tells me
> how many rows were affected.
>
> Using the following input to psql, I got the results:
>
> INSERT 0 0
> UPDATE 0
> DELETE 0
>
> Is this expected? The principle of least suprise suggests to me that
> regardless of the query being rewritten, there is some number of
> tuples being affected, and it would thus still be appropriate to
> return that number.
You are right. It's a bug introduced in 7.2.
Please check the thread [GENERAL]([HACKERS])
Using views and MS access via odbc.
If there's no objection, I would commit the patch
in the thread to both 7.2-stable and the current.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
From pgsql-hackers-owner+M22600@postgresql.org Thu May 9 01:26:14 2002
Return-path: <pgsql-hackers-owner+M22600@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g495QD420463
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 01:26:14 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 1CE274759BC; Thu, 9 May 2002 01:26:14 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 130AE476107; Thu, 9 May 2002 01:25:47 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 8E2AC475EFB
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 01:25:35 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id 52D5D475F20
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 01:24:28 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g495O6W16675;
Thu, 9 May 2002 01:24:06 -0400 (EDT)
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Michael Alan Dorman <mdorman@debian.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <3CD9BFCC.268A52E0@tpf.co.jp>
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp>
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
message dated "Thu, 09 May 2002 09:16:12 +0900"
Date: Thu, 09 May 2002 01:24:05 -0400
Message-ID: <16672.1020921845@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> If there's no objection, I would commit the patch
> in the thread to both 7.2-stable and the current.
Last I checked, I objected to your solution and you objected to mine
... so I think it's on hold until we get some more votes.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
From pgsql-hackers-owner+M22625@postgresql.org Thu May 9 10:08:57 2002
Return-path: <pgsql-hackers-owner+M22625@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49E8u401598
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 10:08:56 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 69C16476171; Thu, 9 May 2002 10:08:37 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id C9CE1476629; Thu, 9 May 2002 09:58:53 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id C57B4476528
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 09:58:42 -0400 (EDT)
Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86])
by postgresql.org (Postfix) with ESMTP id 2CA4147630F
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 09:56:00 -0400 (EDT)
Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1])
by localhost.mallet-assembly.org (Postfix) with ESMTP id E959512F78C
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 09:55:49 -0400 (EDT)
Received: by amanda.mallet-assembly.org (Postfix, from userid 1000)
id D2B9A12F685; Thu, 9 May 2002 09:55:48 -0400 (EDT)
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org>
<3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 09 May 2002 09:55:48 -0400
In-Reply-To: <16672.1020921845@sss.pgh.pa.us>
Message-ID: <87pu05s9wb.fsf@amanda.mallet-assembly.org>
Lines: 57
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Last I checked, I objected to your solution and you objected to mine
> ... so I think it's on hold until we get some more votes.
Well, If I'm reading this code from DBD::Pg's dbdimp.c correctly, I
think that the perl module, at least, feels that the number is much
more important than the actual command that is returned:
if (PGRES_TUPLES_OK == status) {
[...]
} else if (PGRES_COMMAND_OK == status) {
/* non-select statement */
if (! strncmp(cmdStatus, "DELETE", 6) || ! strncmp(cmdStatus, "INSERT", 6) || ! strncmp(cmdStatus, "UPDATE", 6)) {
ret = atoi(cmdTuples);
} else {
ret = -1;
}
It appears that while the implementation does look to make sure the
return string is recognizable, it doesn't care too much beyond that
which one it is---not suprising as that string is, as far as the DBI
interface is concerned, just "extra information" that has no defined
interface to get back out to the user. More important, at least from
the standpoint of a user of the module seems to be that the cmdTuples
(gotten from PQcmdTuples) represents number affected so it can be
returned.
In fact, now that I look at it, this change has in fact broken the
DBD::Pg interface with respect to the DBI when used in the presence of
rules, because the DBI spec states that it will either return the
number of tuples affected or -1 if that is unknown, rather than 0,
which breaks as a result of this change.
I guess there's an argument to be made as to whether PostgreSQL
provides any guarantees about this number being correct or even valid,
but the fact that the library interface makes it available, and I see
nothing in the documentation of the function that suggests that that
number is unreliable suggests that it is not an error to depend on it.
So, If I understood the proposals correctly, I think that means that
this implementation argues for, or at least would work well with,
Hiroshi's solution, since yours, Tom, would return a false zero in
certain (perhaps rare) situations, arguably loosing information that
the perl module, at least, could use, and the library purports to make
available, in order to preserve information it does not.
I guess there is one other possibility, though I don't know how
radical it would be in either implementation or effects: return the
empty string from PQcmdTuples in this situation. It serves as
something of an acknowledgement that what went on was not necessarily
fish or fowl, while still being, from my reading of the docs, a valid
return. The perl module certainly regards it as one, albeit one that
transmits precious little information. Well-written interfaces should
already be able to cope with it, given that it is documented as a
possiblity in the docs, right?
Mike.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
From pgsql-hackers-owner+M22633@postgresql.org Thu May 9 11:00:49 2002
Return-path: <pgsql-hackers-owner+M22633@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49F0m416710
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 11:00:48 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 62204476171; Thu, 9 May 2002 11:00:43 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 097C44767A0; Thu, 9 May 2002 10:44:34 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 2D9044766F0
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 10:44:21 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id D786C476306
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 10:43:27 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g49EhUW19441;
Thu, 9 May 2002 10:43:30 -0400 (EDT)
To: Michael Alan Dorman <mdorman@debian.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <87pu05s9wb.fsf@amanda.mallet-assembly.org>
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org>
Comments: In-reply-to Michael Alan Dorman <mdorman@debian.org>
message dated "09 May 2002 09:55:48 -0400"
Date: Thu, 09 May 2002 10:43:30 -0400
Message-ID: <19438.1020955410@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Michael Alan Dorman <mdorman@debian.org> writes:
> So, If I understood the proposals correctly, I think that means that
> this implementation argues for, or at least would work well with,
> Hiroshi's solution, since yours, Tom, would return a false zero in
> certain (perhaps rare) situations,
IMHO Hiroshi's solution would return false information in more cases
than mine.
The basic argument in favor of a patch like this is that if a rule
replaces (DO INSTEAD) a command with another command of the same general
type, it is useful to return the tag for the replacement command not the
original. I agree with that. I do not agree with the claim that we
should return a tag from the underlying implementation when a rule
rewrites a query into a form totally unrecognizable to the client.
Consider again the example of transforming an UPDATE on a view into
an INSERT on some underlying table --- but let's reverse it now and
suppose it's the other way, the client sends INSERT and the rule
replaces it with an UPDATE. If the client is expecting to get back
"INSERT m n" and actually gets back "UPDATE n", isn't that client
likely to break?
Another issue is that the whole thing falls down if the rewriting
generates more than one query; both Hiroshi's proposal and mine will
not return any substitute tag then. This seems rather restrictive.
Maybe we could have behavior like this: if the original command is
replaced, then use the tag from the last substituted command of the
same class (eg, if you rewrite an UPDATE into an INSERT and an UPDATE,
you get the tag from the UPDATE). If there is *no* substitute command
of the same class, I still believe that returning "UPDATE 0" is correct
behavior. You sent an update, zero tuples were updated, end of story.
There is not scope in this API to tell you about how many tuples might
have been inserted or deleted.
Note that as of CVS tip, the firing order of rules is predictable,
so the rule author can control which substituted command is "the last
one". Without this I don't think that the above would work, but with
it, it seems like a moderately clean answer. Moreover it's at least
somewhat compatible with the pre-7.2.1 behavior --- where you got the
tag from the last command *executed* regardless of any other
considerations. That was definitely broken.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
From pgsql-hackers-owner+M22639@postgresql.org Thu May 9 12:16:27 2002
Return-path: <pgsql-hackers-owner+M22639@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49GGP423508
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 12:16:26 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 0E20447622F; Thu, 9 May 2002 12:16:15 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 3317647656F; Thu, 9 May 2002 12:14:17 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id DBD2B476486
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 12:14:05 -0400 (EDT)
Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86])
by postgresql.org (Postfix) with ESMTP id 95F62476371
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 12:13:33 -0400 (EDT)
Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1])
by localhost.mallet-assembly.org (Postfix) with ESMTP id 2031312F78C
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 12:13:24 -0400 (EDT)
Received: by amanda.mallet-assembly.org (Postfix, from userid 1000)
id 075D312F685; Thu, 9 May 2002 12:13:22 -0400 (EDT)
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org>
<3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us>
<87pu05s9wb.fsf@amanda.mallet-assembly.org>
<19438.1020955410@sss.pgh.pa.us>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 09 May 2002 12:13:22 -0400
In-Reply-To: <19438.1020955410@sss.pgh.pa.us>
Message-ID: <87y9etqoyl.fsf@amanda.mallet-assembly.org>
Lines: 97
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane <tgl@sss.pgh.pa.us> writes:
> The basic argument in favor of a patch like this is that if a rule
> replaces (DO INSTEAD) a command with another command of the same
> general type, it is useful to return the tag for the replacement
> command not the original. I agree with that.
I would argue that the argument in favor of a patch is that there's no
documentation anywhere that behavior changed, or that PQcmdTuples will
not return the expected result in the presence of rules. :-)
Is the change behaviorou propose implementable as a patch to 7.2.1?
> If the client is expecting to get back "INSERT m n" and actually
> gets back "UPDATE n", isn't that client likely to break?
Perhaps. How many clients are checking that the string returned
matches the query it sent?
I've checked DBD::Pg, it doesn't. I've checked psycopg, it doesn't,
though it looks like its handling of the value might be a bit bogus.
ecpg doesn't, though it looks like it might choke on an empty string.
PHP doesn't. QT3 doesn't. PoPY (another Python interface) doesn't.
The TCL library doesn't even look at the return, it just passes it
back, so I suppose there might be applications doing a direct look.
The python lib included with postgresql doesn't. In fact, the idiom
is either (in pseudocode):
if (temp = PQcmdTuples (result)) {
numTuples = atoi (temp);
} else {
numTuples = some other arbitrary value;
}
or:
numTuples = atoi (PQcmdTuples (result));
So, no, my *very* unscientific and non-comprehensive survey suggests
that your fears are mostly groundless. But I haven't seen a single
interface that *is* depending on that being correct, but many of them
return misleading results if PQcmdTuples does.
Which is, if I haven't hammered this enough, not mentioned anywhere in
the documentation.
> Another issue is that the whole thing falls down if the rewriting
> generates more than one query; both Hiroshi's proposal and mine will
> not return any substitute tag then. This seems rather restrictive.
If, when you say, "will not return any substitute tag then.", you mean
that, as an end result PQcmdTuple would return an empty string, well,
that seems reasonable---it keeps the DB from returning bogus info, and
an empty string returned from PQcmdTuple _is_ documented as a valid
response, and it looks like most interfaces would handle it just fine
(except maybe for ecpg, which I would argue either has a bug or I'm
not reading right).
I guess there's the argument to be made that any overly-zealous
interface that might choke on getting a different tag back might also
choke on getting no tag back. But, again, I don't see any doing any
of this. And they *all* seem to expect PQcmdTuples to either return
legitimate data or nothing at all.
> Maybe we could have behavior like this: if the original command is
> replaced, then use the tag from the last substituted command of the
> same class (eg, if you rewrite an UPDATE into an INSERT and an
> UPDATE, you get the tag from the UPDATE). If there is *no*
> substitute command of the same class, I still believe that returning
> "UPDATE 0" is correct behavior. You sent an update, zero tuples
> were updated, end of story.
As long as you document that PQcmdTuples cannot be relied on when
using rules, since the rules might change the query sufficiently to
make it unrecognizable, that's probably OK, though it'll require
significant changes to just about all interface libraries.
> Note that as of CVS tip, the firing order of rules is predictable,
> so the rule author can control which substituted command is "the
> last one". Without this I don't think that the above would work,
> but with it, it seems like a moderately clean answer. Moreover it's
> at least somewhat compatible with the pre-7.2.1 behavior --- where
> you got the tag from the last command *executed* regardless of any
> other considerations. That was definitely broken.
So should I interpret these references to CVS tip as suggesting that
the fix for this change in behavior is not going to be seen until 7.3,
or just that a most-complete fix that tries to deal with multi-rule
invocations would have to wait for 7.3, but that a fix for the simpler
'do instead' case could show up in a 7.2.X release?
Because it seems to me that if we're not going to see a release with a
fix for this change in behavior, we need to make sure that maintainers
of all interfaces know that all bets are off regarding PQcmdTuples in
the (I believe undetectable) presence of rules so they'll make no
effort to use it.
Mike.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
From pgsql-hackers-owner+M22651@postgresql.org Thu May 9 13:48:04 2002
Return-path: <pgsql-hackers-owner+M22651@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49Hm3424831
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 13:48:03 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 85BBD4764FF; Thu, 9 May 2002 13:48:00 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id A414347676B; Thu, 9 May 2002 13:39:19 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 5F794476652
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 13:39:05 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id 09688475BAD
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 13:35:21 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g49HZKW20799;
Thu, 9 May 2002 13:35:20 -0400 (EDT)
To: Michael Alan Dorman <mdorman@debian.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <87y9etqoyl.fsf@amanda.mallet-assembly.org>
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <87y9etqoyl.fsf@amanda.mallet-assembly.org>
Comments: In-reply-to Michael Alan Dorman <mdorman@debian.org>
message dated "09 May 2002 12:13:22 -0400"
Date: Thu, 09 May 2002 13:35:19 -0400
Message-ID: <20796.1020965719@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Michael Alan Dorman <mdorman@debian.org> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> If the client is expecting to get back "INSERT m n" and actually
>> gets back "UPDATE n", isn't that client likely to break?
> Perhaps. How many clients are checking that the string returned
> matches the query it sent?
> I've checked DBD::Pg, it doesn't.
You are confusing client behavior (by which I meant application)
with library behavior. In libpq terms, an application that's sent
an INSERT command might expect to be able to retrieve an OID with
PQoidValue(). Whether the library avoids core-dumping doesn't mean
that the calling app will behave sanely.
> I would argue that the argument in favor of a patch is that there's no
> documentation anywhere that behavior changed, or that PQcmdTuples will
> not return the expected result in the presence of rules. :-)
The motivation for making a change was to try to *preserve* pre-7.2
behavior in the case of INSERTs, where formerly you got back an INSERT
tag even in the presence of ON INSERT DO not-INSTEAD rules. 7.2 broke
that; 7.2.1 fixed that case but changed the behavior for INSTEAD cases.
What we're realizing now is that we need an actually designed behavior,
rather than the implementation artifact that happened to yield pleasant
results most of the time before 7.2.
I'm arguing that the "designed behavior" ought to include the
stipulation that the tag you get back will match the command you sent.
I think that anything else is more likely to confuse clients than help
them.
> Which is, if I haven't hammered this enough, not mentioned anywhere in
> the documentation.
Mainly because no one ever designed the behavior; the pre-7.2
implementation didn't really think about what should happen.
> I guess there's the argument to be made that any overly-zealous
> interface that might choke on getting a different tag back might also
> choke on getting no tag back. But, again, I don't see any doing any
> of this. And they *all* seem to expect PQcmdTuples to either return
> legitimate data or nothing at all.
No, you're still missing the point. PQcmdTuples isn't going to dump
core, because it has no context about what was expected: it sees a tag
and interprets it as best it can, without any idea about what the
calling app might be expecting. What we need to think about here is
what linkage an *application* can reasonably expect between the command
it sends and the tag it gets back (and, hence, the info it can expect to
retrieve from the tag).
> As long as you document that PQcmdTuples cannot be relied on when
> using rules, since the rules might change the query sufficiently to
> make it unrecognizable, that's probably OK, though it'll require
> significant changes to just about all interface libraries.
One more time: there will be zero change in any interface library,
no matter what we do here. The libraries operate at too low a level
to be affected; they have no idea what command you sent. I'm not even
convinced that PQcmdTuples is where to document the issue --- it seems
to me to be a rule question, instead.
> So should I interpret these references to CVS tip as suggesting that
> the fix for this change in behavior is not going to be seen until 7.3,
> or just that a most-complete fix that tries to deal with multi-rule
> invocations would have to wait for 7.3, but that a fix for the simpler
> 'do instead' case could show up in a 7.2.X release?
Until we've decided what *should* happen, it's premature to discuss
whether we can fix it correctly in 7.2.X or should install a quick-hack
change instead. I'd prefer to fix it correctly but we must not let
ourselves be seduced by a quick hack into not thinking about what the
behavior really ideally ought to be. We've done that once too often
already ;-)
FWIW, I'm not at all sure that there will *be* any 7.2.2 release
before 7.3. There hasn't so far been enough volume of fixes to
justify one (no, this problem doesn't justify one IMHO...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
From pgsql-hackers-owner+M22663@postgresql.org Thu May 9 14:49:40 2002
Return-path: <pgsql-hackers-owner+M22663@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g49Ind425928
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 14:49:39 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id CD0D1476627; Thu, 9 May 2002 14:49:37 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 5E96847673E; Thu, 9 May 2002 14:44:15 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 9FD43476470
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 14:44:04 -0400 (EDT)
Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86])
by postgresql.org (Postfix) with ESMTP id BD99947663F
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 14:38:03 -0400 (EDT)
Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1])
by localhost.mallet-assembly.org (Postfix) with ESMTP id 4904C12F78C
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 14:37:50 -0400 (EDT)
Received: by amanda.mallet-assembly.org (Postfix, from userid 1000)
id A06BF12F685; Thu, 9 May 2002 14:37:47 -0400 (EDT)
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org>
<3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us>
<87pu05s9wb.fsf@amanda.mallet-assembly.org>
<19438.1020955410@sss.pgh.pa.us>
<87y9etqoyl.fsf@amanda.mallet-assembly.org>
<20796.1020965719@sss.pgh.pa.us>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 09 May 2002 14:37:47 -0400
In-Reply-To: <20796.1020965719@sss.pgh.pa.us>
Message-ID: <87znz9p3pg.fsf@amanda.mallet-assembly.org>
Lines: 71
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane <tgl@sss.pgh.pa.us> writes:
> You are confusing client behavior (by which I meant application)
> with library behavior. In libpq terms, an application that's sent
> an INSERT command might expect to be able to retrieve an OID with
> PQoidValue(). Whether the library avoids core-dumping doesn't mean
> that the calling app will behave sanely.
No, Tom, I'm not confusing them. I'm in no way concerned with
PQcmdTuple coredumping because the published interface specifies that
it can return a null string if it finds it necessary, which implies
that somewhere down there it's doing some decent error handling to
figure out if it's gotten something back it can make sense of and
acting appropriately.
You brought up core dumps. My concern has been exclusively with the
potential change in behavior this can cause in applications.
So I've been doing is going and downloading the source to, and looking
at the behavior of, some of the libraries that some---probably many,
maybe even most---clients are using, those for perl and python and
php, and I am finding that most of them do not even expose the
information whose (mis-)interpretation concerns you.
So, for those interfaces, at least, there was no problem to be fixed
in the first place.
Still, you don't have to have something actively breaking to warrant
fixing a bug, so there's no reason to have not made the change that
was made.
The problem is that, at the same time, I am finding that the change to
postgresql 7.2 may make application code using those interfaces begin
to operate in new and different ways because, although they aren't
paying attention to the string, which you are concerned with, they
*are* paying attention to the numbers.
Many of those interfaces, where they used to return 1 or 10 or 5000 or
6432456, will now be returning 0, which thanks to the great C
tradition, is often interpreted to mean "false", which may lead an
application to question why "nothing happened." As mine did.
And this isn't necessarily application programmers making bad choices;
the Perl interface, at least, documents the fact that it returns the
number of rows affected or -1 if that is unknowable---but the change
in behavior leads the perl interface to think it knows, when in fact
it doesn't.
If I knew java better, I'd check the JDBC driver. I mean, imagine:
Perl, python, php and java, all with undocumented unpredictable
behavior in the presence of 'update do instead' rules. Break all four
and you've just created a potential problem for everyone who does web
development.
That, I think, is one of the more egregious changes in behavior I've
seen in the few years I've been following PostgreSQL, and yet not only
is there any documentation, I feel like I'm having to fight to even
get it acknowledge that it is the bigger problem than the blasted
strings not matching because it affects a heck of a lot more stuff in
a much more direct manner.
Still, handle this however you want. I'll go fix the Perl driver to
pretend PQcmdTuples doesn't exist, since it can't be trusted to
deliver reliable information, and just have it return -1, and *my*
apps will be OK. Maybe some months down the road when 7.3 finally
straggles into view there will be a solution. Hopefully no one will
have been burned.
Anyway, I'm done beating this dead horse, since the display is
obviously bothering people.
Mike.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
From pgsql-hackers-owner+M22695@postgresql.org Thu May 9 21:16:21 2002
Return-path: <pgsql-hackers-owner+M22695@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A1GK400881
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 21:16:20 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id ADD4F4767FA; Thu, 9 May 2002 21:16:06 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 643D247691E; Thu, 9 May 2002 21:15:49 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 4B0CF47630B
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 21:15:29 -0400 (EDT)
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by postgresql.org (Postfix) with SMTP id B9FB2475F13
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 21:15:22 -0400 (EDT)
Received: (qmail 1794 invoked from network); 10 May 2002 01:15:25 -0000
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
by sd2.tpf-fw-c.co.jp with SMTP; 10 May 2002 01:15:25 -0000
Received: from tpf.co.jp ([126.0.1.68])
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id KAA09847;
Fri, 10 May 2002 10:15:23 +0900 (JST)
Message-ID: <3CDB1F82.BFE2CC5C@tpf.co.jp>
Date: Fri, 10 May 2002 10:16:50 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Michael Alan Dorman <mdorman@debian.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane wrote:
>
> Michael Alan Dorman <mdorman@debian.org> writes:
> > So, If I understood the proposals correctly, I think that means that
> > this implementation argues for, or at least would work well with,
> > Hiroshi's solution, since yours, Tom, would return a false zero in
> > certain (perhaps rare) situations,
>
> IMHO Hiroshi's solution would return false information in more cases
> than mine.
My solution never returns false information as to
patched cases though the returned result may be
different from the one clients expect.
Probably your solution doesn't return false
information either if 'UPDATE 0' means UPDATE 0
but unknown INSERT/DELETEs. But few(maybe no ?)
clients seem to think of it and what could clients
do with such infos in the first place ?
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
From pgsql-hackers-owner+M22696@postgresql.org Thu May 9 21:28:00 2002
Return-path: <pgsql-hackers-owner+M22696@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A1S0400995
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 21:28:00 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id 8D3EC4768F7; Thu, 9 May 2002 21:27:54 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id C60E347686A; Thu, 9 May 2002 21:27:40 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 9DDB6475EF2
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 21:27:22 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id 8D51A475D9D
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 21:27:21 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4A1R8W24994;
Thu, 9 May 2002 21:27:08 -0400 (EDT)
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Michael Alan Dorman <mdorman@debian.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <3CDB1F82.BFE2CC5C@tpf.co.jp>
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp>
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
message dated "Fri, 10 May 2002 10:16:50 +0900"
Date: Thu, 09 May 2002 21:27:08 -0400
Message-ID: <24991.1020994028@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Of cource it is nice to have a complete solution
> immediately but it doesn't seem easy. My patch is
> only a makeshift solution but fixes the most
> siginificant case(typical updatable views).
I would like to devise a complete solution *before* we consider
installing makeshift solutions (which will institutionalize wrong
behavior).
There seems to be some feeling here that in the presence of rewrites
you only want to know that "something happened". Are you suggesting
that the returned tuple count should be the sum of all counts from
insert, update, and delete actions that happened as a result of the
query? We could certainly implement that, but it does not seem like
a good idea to me.
I'm also concerned about having an understandable definition for the
OID returned for an INSERT query --- if there are additional INSERTs
triggered by rules, does that mean you don't get to see the OID assigned
to the single row you tried to insert? You'll definitely get push-back
if you propose that. But if we add up all the actions for the generated
queries, we are quite likely to be returning an OID along with an insert
count greater than one --- which is certainly confusing, as well as
contrary to the existing documentation about how it works.
Let's please quit worrying about "can we install a hack today" and
instead try to figure out what a sensible behavior is. I don't think
it's likely to be hard to implement anything we might come up with,
considering how tiny this API is.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
From pgsql-hackers-owner+M22699@postgresql.org Thu May 9 22:36:27 2002
Return-path: <pgsql-hackers-owner+M22699@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4A2aR401628
for <pgman@candle.pha.pa.us>; Thu, 9 May 2002 22:36:27 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id EECB1476843; Thu, 9 May 2002 22:36:22 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 2B1B34768E5; Thu, 9 May 2002 22:35:39 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 267D2476860
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 22:35:28 -0400 (EDT)
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by postgresql.org (Postfix) with SMTP id 1BE8447590B
for <pgsql-hackers@postgresql.org>; Thu, 9 May 2002 22:34:30 -0400 (EDT)
Received: (qmail 10177 invoked from network); 10 May 2002 02:34:34 -0000
Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108)
by sd2.tpf-fw-c.co.jp with SMTP; 10 May 2002 02:34:34 -0000
Received: from tpf.co.jp ([126.0.1.68])
by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id LAA09898;
Fri, 10 May 2002 11:34:33 +0900 (JST)
Message-ID: <3CDB320F.55B00318@tpf.co.jp>
Date: Fri, 10 May 2002 11:35:59 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Michael Alan Dorman <mdorman@debian.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp> <24991.1020994028@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Of cource it is nice to have a complete solution
> > immediately but it doesn't seem easy. My patch is
> > only a makeshift solution but fixes the most
> > siginificant case(typical updatable views).
>
> I would like to devise a complete solution *before* we consider
> installing makeshift solutions (which will institutionalize wrong
> behavior).
>
> There seems to be some feeling here that in the presence of rewrites
> you only want to know that "something happened". Are you suggesting
> that the returned tuple count should be the sum of all counts from
> insert, update, and delete actions that happened as a result of the
> query? We could certainly implement that, but it does not seem like
> a good idea to me.
What should the backends return for complicated rewrites ?
And how should/could clients handle the results ?
It doesn't seem easy to me and it seems a flaw of rule
system. Honestly I don't think that the psqlodbc driver
can guarantee to handle such cases properly.
However both Ron's case and Michael's one are ordinary
updatable views. If we can't handle the case properly,
we could never recommend users to use (updatable) views.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
From pgsql-hackers-owner+M22704@postgresql.org Fri May 10 06:34:07 2002
Return-path: <pgsql-hackers-owner+M22704@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4AAY6406914
for <pgman@candle.pha.pa.us>; Fri, 10 May 2002 06:34:07 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id E649F476131; Fri, 10 May 2002 06:33:54 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 77EB447672A; Fri, 10 May 2002 06:30:40 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id A391F4762CD
for <pgsql-hackers@postgresql.org>; Fri, 10 May 2002 06:30:24 -0400 (EDT)
Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114])
by postgresql.org (Postfix) with SMTP id 75A4A47620B
for <pgsql-hackers@postgresql.org>; Fri, 10 May 2002 06:30:18 -0400 (EDT)
Received: from h00045a2e4e7c.ne.client2.attbi.com (HELO saturn.janwieck.net) (janwieck@24.61.137.137 with login)
by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 May 2002 10:30:19 -0000
Received: (from wieck@localhost)
by saturn.janwieck.net (8.11.2/8.11.2) id g4AAJGD03410;
Fri, 10 May 2002 06:19:16 -0400
From: Jan Wieck <janwieck@yahoo.com>
Message-ID: <200205101019.g4AAJGD03410@saturn.janwieck.net>
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <24991.1020994028@sss.pgh.pa.us> from Tom Lane at "May 9, 2002 09:27:08
pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 10 May 2002 06:19:16 -0400 (EDT)
cc: Hiroshi Inoue <Inoue@tpf.co.jp>, Michael Alan Dorman <mdorman@debian.org>,
pgsql-hackers@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: ORr
Tom Lane wrote:
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Of cource it is nice to have a complete solution
> > immediately but it doesn't seem easy. My patch is
> > only a makeshift solution but fixes the most
> > siginificant case(typical updatable views).
>
> I would like to devise a complete solution *before* we consider
> installing makeshift solutions (which will institutionalize wrong
> behavior).
>
> There seems to be some feeling here that in the presence of rewrites
> you only want to know that "something happened". Are you suggesting
> that the returned tuple count should be the sum of all counts from
> insert, update, and delete actions that happened as a result of the
> query? We could certainly implement that, but it does not seem like
> a good idea to me.
IMHO the answer should only be a number if the rewritten
querytree list consists of one query of the same command
type. everything else has to lead into "unknown".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
From pgsql-hackers-owner+M22723@postgresql.org Fri May 10 10:56:10 2002
Return-path: <pgsql-hackers-owner+M22723@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4AEu9418485
for <pgman@candle.pha.pa.us>; Fri, 10 May 2002 10:56:09 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id AA205475C2C; Fri, 10 May 2002 10:55:46 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id E96B447667B; Fri, 10 May 2002 10:51:45 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id D46CF475A00
for <pgsql-hackers@postgresql.org>; Fri, 10 May 2002 10:51:34 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id 09489475A04
for <pgsql-hackers@postgresql.org>; Fri, 10 May 2002 10:51:30 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4AEp5W28246;
Fri, 10 May 2002 10:51:06 -0400 (EDT)
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Michael Alan Dorman <mdorman@debian.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <3CDB320F.55B00318@tpf.co.jp>
References: <87znzaqlv2.fsf@amanda.mallet-assembly.org> <3CD9BFCC.268A52E0@tpf.co.jp> <16672.1020921845@sss.pgh.pa.us> <87pu05s9wb.fsf@amanda.mallet-assembly.org> <19438.1020955410@sss.pgh.pa.us> <3CDB1F82.BFE2CC5C@tpf.co.jp> <24991.1020994028@sss.pgh.pa.us> <3CDB320F.55B00318@tpf.co.jp>
Comments: In-reply-to Hiroshi Inoue <Inoue@tpf.co.jp>
message dated "Fri, 10 May 2002 11:35:59 +0900"
Date: Fri, 10 May 2002 10:51:05 -0400
Message-ID: <28243.1021042265@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> What should the backends return for complicated rewrites ?
Well, given that we have only two or three fields to work in,
it obviously has to be a very simplified view of what happened.
But we have to define *something*.
> And how should/could clients handle the results ?
> It doesn't seem easy to me and it seems a flaw of rule
> system.
No, the problem is that the command tag API was designed without any
thought for rule rewriting. But I don't think it's worth revising
that API completely. Even if we did, we'd still have to define what
behavior would be seen by clients that use the existing PQcmdTuples,
etc, calls; so we'd still have to solve these same issues.
Come on, guys, work with me a little here. I've thrown out several
alternative suggestions already, and all I've gotten from either of
you is refusal to think about the problem.
I was thinking last night that it might help to break down the issue a
little bit. We have either two or three result fields to think about:
the tag name, the tuple count, and in the case of INSERT the inserted
row OID. Let's consider each one independently.
1. The tag name: AFAICS, this ought *always* to match the type of the
original command submitted by the client. Doing otherwise could confuse
clients that are submitting multiple commands per query string.
Besides, the only possible downside from making this requirement is that
we couldn't send back an insertion OID when the original command was
an update or delete. How likely is it that a client would expect to
be able to get an insertion OID from such a command?
2. The inserted row OID: per above, will be supplied only if the
original command was an INSERT. If the original insert command is
not removed (no INSTEAD rule), then I think this result should clearly
come from the execution of the original command, regardless of any
additional INSERTs added by rules. If the original command is removed
by INSTEAD, then we can distinguish three sub-cases:
a. No INSERTs in rewriter output: easy, we must return 0.
b. Exactly one INSERT in rewriter output: pretty easy to agree that
we should return this command's result.
c: More than one INSERT in rewriter output: we have a couple of
possibilities here. It'd be reasonable to directly use the
result of the last INSERT, or we could total the results of
all the INSERTs (ie, if taken together they insert a sum total
of one row, return that row OID; else return 0). Maybe there
are other possible behaviors. Any thoughts?
3. The tuple count: this seems the most contentious issue. Again,
if there is no INSTEAD rule I'd be strongly inclined to say we
should just return the count from the original command, ignoring any
commands added by rules. If there is an INSTEAD, we've discussed
several possibilities: use result of last command in the rewritten
series, use result of last command of same type as original command,
sum up the results of all the rewritten commands, maybe some others
that I forgot.
Given Michael's concern about being able to "tell that something
happened", I'm inclined to go with the summing-up behavior in the
INSTEAD cases. This would lead to the following boiled-down behavior:
A. If original command is executed (no INSTEAD), return its tag as-is,
regardless of commands added by rules.
B. If original command is not executed, then return its tag name
plus required fields defined as follows: tuple count is sum of tuple
counts of all replacement commands. For an INSERT, if the replacement
commands taken together inserted a grand total of exactly one tuple,
return that tuple's OID; else return 0.
This is not completely consistent in pathological cases: you could get
a tuple OID returned even when the returned tuple count is greater
than one, which is not a possible case currently. (This would happen
given a rewrite consisting of a single-row INSERT plus additional
update or delete actions that affect some rows.) But that seems
pretty oddball. In all the simple cases I think this proposal gives
reasonable behavior.
A tighter definition for case B would use the sum of the tuple counts
of only the replacement actions that are of the same type as the
original command. This would eliminate the possible inconsistency
between tuple count and insert OID results, and it's arguably saner
than the above proposal: "if it says UPDATE 4, that should mean that
four rows were updated, not that something else happened to four rows".
But it would not meet Michael's concern about using PQcmdTuples to
tell that "something happened". I could live with either definition.
Thoughts, different proposals, alternative ways of breaking down
the problem?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
From pgsql-hackers-owner+M22899@postgresql.org Thu May 16 16:31:02 2002
Return-path: <pgsql-hackers-owner+M22899@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4GKV2B23639
for <pgman@candle.pha.pa.us>; Thu, 16 May 2002 16:31:02 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id EDDEF4762F9; Thu, 16 May 2002 16:30:59 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 52CE1476519; Thu, 16 May 2002 16:30:28 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id 92A34475C8A
for <pgsql-hackers@postgresql.org>; Thu, 16 May 2002 16:30:14 -0400 (EDT)
Received: from amanda.mallet-assembly.org (durham-24-086.biz.dsl.gtei.net [4.3.24.86])
by postgresql.org (Postfix) with ESMTP id 0E8A3475BBE
for <pgsql-hackers@postgresql.org>; Thu, 16 May 2002 16:30:13 -0400 (EDT)
Received: from localhost.localdomain (amanda.mallet-assembly.org [127.0.0.1])
by localhost.mallet-assembly.org (Postfix) with ESMTP id DDA4412F78C
for <pgsql-hackers@postgresql.org>; Thu, 16 May 2002 16:30:03 -0400 (EDT)
Received: by amanda.mallet-assembly.org (Postfix, from userid 1000)
id CF2A912F685; Thu, 16 May 2002 16:30:01 -0400 (EDT)
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
References: <200205101019.g4AAJGD03410@saturn.janwieck.net>
<28286.1021042653@sss.pgh.pa.us>
From: Michael Alan Dorman <mdorman@debian.org>
Date: 16 May 2002 16:30:01 -0400
In-Reply-To: <28286.1021042653@sss.pgh.pa.us>
Message-ID: <874rh7rg3a.fsf@amanda.mallet-assembly.org>
Lines: 47
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Michael seems to feel that the tuple count should be nonzero if any
> of the replacement operations did anything at all. This does not
> make a lot of sense at the command tag level ("UPDATE 4" might not
> mean that 4 tuples were updated) but if you look at the definition
> of PQcmdTuples ("returns the number of rows affected by the SQL
> command") it's not so unreasonable. And I can see the point of
> wanting to know whether anything happened.
Close.
It's not so much that I want to know exactly what happened, it's that
I want to know that if PostgreSQL says nothing happened, then I can be
sure that nothing happened, rather than being told that nothing
happened when something happened, and vice versa.
In fact, my suggestion---which might suffer from issues that I am not
aware of, perhaps the ones that led to the patch in the first
place---would be that, given ambiguity, have the system return
something that would cause PQcmdTuples to return an empty string (I'm
assuing this would be a result string with no numbers attached at
all).
It is documented, after all, as being the return value when the system
cannot determine an otherwise correct number, and all of the code I
looked at would, I believe, cope gracefully with it, returning what
I'm guessing (except in the Perl case, where I'm sure) is a sentinel
value indicating, "it worked, but I have no idea how many tuples were
involved".
But I'm not wedded to that---I just don't want to get an answer back
that might lead me off into the woods.
As for the issue of whether the tag is the same or not, I am utterly
pragmatic---I don't use it, and don't really have a way to get to it
from the interfaces I use, so I think the best option is probably
something where the rules to describe it are straightforward to
minimize confusion and support issues. And it should be documented
appropriately.
I mean, even when this is resolved, we should probably be putting
something in the documentation that says that PQcmdTuples can really
only really be depended upon as a tri-state value: 0 ("nothing
happened"), >0 ("something happened"), empty string ("heck if I
know").
Mike.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
From pgsql-hackers-owner+M22911@postgresql.org Fri May 17 13:56:43 2002
Return-path: <pgsql-hackers-owner+M22911@postgresql.org>
Received: from postgresql.org (postgresql.org [64.49.215.8])
by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id g4HHugB12591
for <pgman@candle.pha.pa.us>; Fri, 17 May 2002 13:56:43 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP
id D1FCF475FB7; Fri, 17 May 2002 13:44:22 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id 391334765F6; Fri, 17 May 2002 13:37:17 -0400 (EDT)
Received: from localhost.localdomain (postgresql.org [64.49.215.8])
by localhost (Postfix) with ESMTP id ADCE94764EF
for <pgsql-hackers@postgresql.org>; Fri, 17 May 2002 13:37:04 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
by postgresql.org (Postfix) with ESMTP id 6E63F476886
for <pgsql-hackers@postgresql.org>; Fri, 17 May 2002 12:59:21 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4HDV8W03879;
Fri, 17 May 2002 09:31:08 -0400 (EDT)
To: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Queries using rules show no rows modified?
In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA4961DD1@m0114.s-mxs.net>
References: <46C15C39FEB2C44BA555E356FBCD6FA4961DD1@m0114.s-mxs.net>
Comments: In-reply-to "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
message dated "Fri, 17 May 2002 08:53:04 +0200"
Date: Fri, 17 May 2002 09:31:08 -0400
Message-ID: <3876.1021642268@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: ORr
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Michael seems to feel that the tuple count should be nonzero if any
>> of the replacement operations did anything at all.
> Here we usually add triggers, for replication, accounting, setting of
> calculated rows ... In all of our cases we want the addition of a trigger
> (or rule on a table) to be transparent to the client.
Yeah. Triggers wouldn't affect this anyway, unless they tell the system
to suppress insertion/update/deletion of some tuples, in which case I
think it is correct not to count those tuples (certainly that's how the
code has always acted). As far as rules go, the last proposal that I
made would return the tuple count of the original query as long as there
were no INSTEAD rules --- if you have only actions *added* by rules then
they are transparent.
The hard case is where the original query is not executed because of an
INSTEAD rule. As the code presently stands, you get "UPDATE 0" (or
INSERT or DELETE 0) in that case, regardless of what else was done
instead by the rule. I thought that was OK when we put the change in,
but it seems clear that people do not like that behavior. The notion
of "keep it transparent" doesn't seem to help here.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
View Git Blame Copy Permalink