mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-27 08:39:28 +08:00
1364 lines
64 KiB
Plaintext
1364 lines
64 KiB
Plaintext
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
|
|
|