Re: [HACKERS] ATTN: Tom Lane
On Fri, 2002-06-14 at 02:10, David Ford wrote: ... while talking to sss.pgh.pa.us.: MAIL From:[EMAIL PROTECTED] 550 5.7.1 Probable spam from 68.9.71.221 refused - see http://www.five-ten-sg.com/blackhole.php?68.9.71.221 554 5.0.0 Service unavailable Tom, if you block everyone on cable, dialup, dsl, and adsl, then you're probably blocking a lot of legitimate mail. I don't feel like paying some Big Company just so I can relay mail through them when I can do my company's own mail on my own networks. Big Company will get blacklisted soon enough for [inadvertently] allowing a spammer to send mail through them. Please don't punish the victim until they're proven guilty. David p.s. There isn't any contact address on the above URL for the requested updates. You can manually decode an e-mail address from the first line on that site : You can always send email to blackhole3 at five-ten-sg.com even if your mail server is listed here. I got my home ADSL un-blacklisted after a few emails to them when they agreed that my IP is actually static. --- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Non-standard feature request
On Thu, 13 Jun 2002, Mike Mascari wrote:
CREATE TEMPORARY TABLE
...
ON COMMIT DROP;
pseudo-compatible with the SQL-standard of:
ON COMMIT { DELETE | PRESERVE } ROWS;
so one day PostgreSQL's grammar would look like:
...
ON COMMIT { DROP | { DELETE | PRESERVE } ROWS };
I think this is a pretty useful feature. Shouldn't require too much
work. A new relkind or a bool in TempTable and a little code in
AtEOXact_temp_relations() to heap_drop_with_catalog() the registered temp
table.
Anyone else keen for this feature?
Gavin
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Language Comments
What is the preferred method (if there even is one) for modifying the comment on a language? I vaguely remember it being documented that it was stored in pg_language.lancompiler and specified using the LANCOMPILER option to CREATE LANGUAGE or by updating the record directly. pgAdmin has done it this way for years but during a scouring of the docs today, I notice that LANCOMPILER is no longer mentioned and there is no COMMENT ON LANGUAGE to replace it. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostGres Doubt
pg_auth=# select version(); version PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 3.0.2 Which btw has a curious grant/revoke bug. create foo; grant select on foo to bar; results in all rights being granted. You must revoke and grant again in order to get the correct rights set. If this rights bug has been fixed, I'll upgrade, but I don't consider it a big problem since I am well aware of the bug. David Bruce Momjian wrote: David Ford wrote: I'm using md5 in pg_hba.conf. That is the method, no? I'm writing a milter application which instantiates a private resource for each thread upon thread startup. I have priv-conn which I establish as priv-conn=PQconnectdb(connstr), connstr is const char *connstr=host=10.0.0.5 dbname=bmilter user=username password=password; It segfaults depending on it's mood but it tends to happen about 50-70% of the time. I switched to PQsetdbLogin() which has worked perfectly. I don't really want to use that however, I would much prefer using my connstr. Wow, I am confused. md5 should be fine. Certainly sounds like there is a thread problem with PQconnectdb(). Are you using 7.2.X? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Language Comments
Dave Page [EMAIL PROTECTED] writes: What is the preferred method (if there even is one) for modifying the comment on a language? There isn't one. Certainly LANCOMPILER was *never* meant as a place to store comments. I suppose a COMMENT ON LANGUAGE facility could be added, but I can't get very excited about it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Language Comments
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 14 June 2002 14:49 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] Language Comments Dave Page [EMAIL PROTECTED] writes: What is the preferred method (if there even is one) for modifying the comment on a language? There isn't one. Certainly LANCOMPILER was *never* meant as a place to store comments. It was in the docs until v1.14 (doc/src/sgml/ref/create_language.sgml) when Peter removed it for 1.15 - I therefore made use of the feature in pgAdmin... I only noticed it wasn't there 'cos I was trawling the docs looking for new/missing features to add to pgAdmin. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] SQL99 feature list
As you probably know, SQL99 has dropped the rather useless categorizations of basic, intermediate, and advanced SQL compliance and instead lists a large number of labeled features. I've put these into an appendix for the docs (not yet committed to cvs). The list is organized as a (for now) three column table, with Feature, Description, and Comment as the three column headers. This is a relatively long list, covering several printed pages. So, a question: should I list all features in the same table, with the comment field indicating if something is not (yet) supported, or should I split the features into two tables for supported and unsupported features? The former keeps all of the information together if someone is looking something up by feature, and the latter reduces the number of required comments and makes it easier to see the complete list of supported features. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Non-standard feature request
Tom Lane wrote: Mike Mascari [EMAIL PROTECTED] writes: ... Would it be possible to have either a GUC setting or a grammar change to allow TEMPORARY tables to be dropped at transaction commit? This seems like a not unreasonable idea; but the lack of other responses suggests that the market for such a feature isn't there. Perhaps you should try to drum up some interest on pgsql-general and/or pgsql-sql. I was wondering if it made sense to remove temp tables on transaction finish if the temp table was created in the transaction? That wouldn't require any syntax change. Seems non-standard though, and I can imagine a few cases where you wouldn't want it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Indexing for DESC sorts
Tom, Bruce, Back in 7.1.0, we had a problem where no index could be used on ORDER BY ... DESC statements. Has this been fixed? I'm writing an article on indexing. -Josh Berkus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Breakage in crypt.c
There are various paths of control in md5_crypt_verify that do if (passwd) pfree(passwd); if (valuntil) pfree(valuntil); Isn't this now pfree'ing part of the saved pre-parsed pg_pwd data? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Big Test Environment Feature
Question: How feasible would it be to create this functionality in PostgreSQL: One creates a test version of a database that initially consists of read-links to the production version of the same database. Any code he/she then writes that reads from a table reads from the production database but any code that modifies data copies that table to the test database. The benefits of this are obviously huge for IT shops that need to constantly work on data in test environments as similar as possible to the production environment. Usually, this is a very difficult aspect of one's work and represents a great deal of risk. We always try to hard to ensure that what we migrate into production is going to work there the same as it did in test. And we should not do testing in a production environment. Such a feature would give PostgreSQL a major advantage over Oracle or DB2. And some day when PostgreSQL is also distributable, it'll be ideal for the enterprise. Matthew -- Anything that can be logically explained, can be programmed. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] ATTN: Tom Lane
Tom Lane wrote: David Ford [EMAIL PROTECTED] writes: Tom, if you block everyone on cable, dialup, dsl, and adsl, then you're probably blocking a lot of legitimate mail. David, let me explain this in words of one syllable: I am currently rejecting upwards of 2000 spam messages per day. If I did not have extremely stringent filters in place, email would be completely useless to me. Advice suggesting that I weaken my filters will be ignored with as much grace as I can muster, which on most days is not a lot. This is what comes of having several well-publicized email addresses :-( I sympathize with your pain. However, I've found that the five-ten-sg.com list is ofter overly aggressive. There are many other RBL's that are not as aggressive and used in combination provide very good results. Also, you could even try SpamCop's RBL, if your so inclined. I could not post from my work address to any of the lists strictly because of the five-ten-sg.com RBL. They blocked everything from BellSouth's IP allocation blocks. They only way around it is to beg them to allow you a static IP and the ask to have that IP unbanned from the RBL. It's a lot of work. RBL's are good, but I think the one that blocked David Ford and myself is perhaps a little too strong. Just my two cents. Thomas
Re: [HACKERS] [JDBC] Shouldn't aborted transaction be an ERROR? (was Re:
I have just tested this on the latest code using the following
Connection con = JDBC2Tests.openDB();
try
{
// transaction mode
con.setAutoCommit(false);
Statement stmt = con.createStatement();
stmt.execute(select 1/0);
fail( Should not execute this, as a SQLException s/b thrown
);
con.commit();
}
catch ( Exception ex )
{
}
try
{
con.commit();
con.close();
}catch ( Exception ex) {}
}
and it executes as expected. It throws the SQLException and does not
execute the fail statement
Thanks,
Dave
On Wed, 2002-06-12 at 12:12, Tom Lane wrote:
John Taylor [EMAIL PROTECTED] writes:
On Wednesday 12 June 2002 16:36, Tom Lane wrote:
Queries after the failure aren't run at all; they're only passed through
the parser's grammar so it can look for a COMMIT or ROLLBACK command.
Normal processing resumes after ROLLBACK. If you were paying attention
to the return codes you'd notice complaints like
regression=# begin;
BEGIN
regression=# select 1/0;
ERROR: floating point exception! The last floating point operation either
exceeded legal ranges or was a divide by zero
-- subsequent queries will be rejected like so:
regression=# select 1/0;
WARNING: current transaction is aborted, queries ignored until end of
transaction block
*ABORT STATE*
Well, I'm using JDBC, and it isn't throwing any exceptions, so I
assumed it was working :-/
This brings up a point that's bothered me in the past. Why is the
queries ignored response treated as a NOTICE and not an ERROR?
A client that is not paying close attention to the command result code
(as JDBC is evidently not doing :-() might think that its command had
been executed.
It seems to me the right behavior is
regression=# select 1/0;
ERROR: current transaction is aborted, queries ignored until end of transaction
block
regression=#
I think the reason why it's been done with a NOTICE is that if we
elog(ERROR) on the first command of a query string, we'll not be able to
process a ROLLBACK appearing later in the same string --- but that
behavior does not seem nearly as helpful as throwing an error.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] FEATURE REQUEST - More dynamic date type?
Thanks for reading. A few disclaimers: 1. I am a newbie. I program for a living, but my work in pg has so far been at the devoted hobby level, using pg and PHP. For an example of what I have done with pg, you can visit www.the-athenaeum.org, a site I one day hope to make into a business. 2. I've searched the boards, but can't find a good solution to my problem. I realize that there may be better ways to solve my issues than expanding pg's feature set, or there may be features I'm not familiar with. This message is partly to find out how I should approach my problem. 3. I know you are all busy, and there are more pressing issues. I am extremely grateful for any advice you can give me, and will be ecstatic if I can get a solution out of this. So, on to my issue. THE BACKGROUND - I am creating a web site where people can study the humanities. They can upload, discuss, and peer-review information. They can also create, edit, approve, and delete records in a postgresql db, using web forms. Many of these forms need a way to enter historical dates - a person DOB, the date an empire was founded, the date a book was published, etc. MY PROBLEM - Because this site deals with, among other things, ancient art, acheaology, and anthropology, I need a way to handle dates as specific as a single day, and as far back as 100,000 BC. According to the docs (I looked at http://www.postgresql.org/idocs/index.php?datatype-datetime.html), the farthest back any date type reaches is 4713 BC. So far, I have tried to deal with this problem by creating a numeric field for the year, and radio buttons for AD/BC. I then do a lot of form validation. Not only that, if I want to be as specific as a month or a day, then those are separate fields on my forms. Plus, I can't combine all of the fields and put them into a pg data type, because once again, they don't extend that far back. So, I have to maintain and validate the year, month, and days fields separately. Then imagine what I have to do if a user wants to _sort_ by date, or select events by date range! Ideally, I would like to figure this out on two fronts. I'd like to find out what's the best way to store dates that far back (with pg), and then on the PHP end I'll have to figure out how to parse entry so that it is as simple as possible for the end user. Knowing how to store these ancient dates in pg would help me a great deal. There are a lot of university and hobby sites out there working on digitizing collections of ancient texts, artifacts, etc. I don't know how the date range is chosen for a type like timestamp (4713BC - 1,465,001 AD), but it seems to me that there would be way more people working on recording the past (and thereby needed a date range that extends into ancient civilization) than working with dates in the far future (more than a million years ahead???). I hope that someone will be kind enough to reply with some ideas, or even to take up the cause and consider a date type that could be used for historical purposes. I am an avid fan of open source and pg, especially as compared to mySQL. I hope to continue using pg, and build a first-class web site that may one day serve as a great working example of what pg can do. Any help would be greatly appreciated. Thanks in advance, Chris McCormick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Big Test Environment Feature
Matthew Tedder wrote: Question: How feasible would it be to create this functionality in PostgreSQL: One creates a test version of a database that initially consists of read-links to the production version of the same database. Any code he/she then writes that reads from a table reads from the production database but any code that modifies data copies that table to the test database. The benefits of this are obviously huge for IT shops that need to constantly work on data in test environments as similar as possible to the production environment. Usually, this is a very difficult aspect of one's work and represents a great deal of risk. We always try to hard to ensure that what we migrate into production is going to work there the same as it did in test. And we should not do testing in a production environment. Such a feature would give PostgreSQL a major advantage over Oracle or DB2. And some day when PostgreSQL is also distributable, it'll be ideal for the enterprise. Matthew Why wouldn't you use a pg_dump of the production database? Perhaps just a sampling every so often? This sounds like a lot of unnecessary work for the engine. How about a seperate program which has notify links to the source database and places updated data in the test db? - Bill ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Non-standard feature request
Bruce Momjian wrote: Tom Lane wrote: Mike Mascari [EMAIL PROTECTED] writes: ... Would it be possible to have either a GUC setting or a grammar change to allow TEMPORARY tables to be dropped at transaction commit? This seems like a not unreasonable idea; but the lack of other responses suggests that the market for such a feature isn't there. Perhaps you should try to drum up some interest on pgsql-general and/or pgsql-sql. I was wondering if it made sense to remove temp tables on transaction finish if the temp table was created in the transaction? That wouldn't require any syntax change. Seems non-standard though, and I can imagine a few cases where you wouldn't want it. That is what I want to do, except by extending the grammar. I must admit to actually being surprised that a TEMP table created inside a transaction lived after the transaction completed. That's when I looked at the standard and saw that PostgreSQL's implementation was correct. I would think for most people session-long temp tables are more the exception than the rule. But I guess SQL92 doesn't think so. Regardless, a couple of other people have shown some interest in the idea. I'll post it to general as well as Tom suggests... Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FEATURE REQUEST - More dynamic date type?
On Thu, Jun 13, 2002 at 11:39:55 -0400, Chris McCormick [EMAIL PROTECTED] wrote: Thanks for reading. A few disclaimers: MY PROBLEM - Because this site deals with, among other things, ancient art, acheaology, and anthropology, I need a way to handle dates as specific as a single day, and as far back as 100,000 BC. According to the docs (I looked at http://www.postgresql.org/idocs/index.php?datatype-datetime.html), the farthest back any date type reaches is 4713 BC. So far, I have tried to deal with this problem by creating a numeric field for the year, and radio buttons for AD/BC. I then do a lot of form validation. Not only that, if I want to be as specific as a month or a day, then those are separate fields on my forms. Plus, I can't combine all of the fields and put them into a pg data type, because once again, they don't extend that far back. So, I have to maintain and validate the year, month, and days fields separately. Then imagine what I have to do if a user wants to _sort_ by date, or select events by date range! Is there really a standard for how long individual months were in 10BC! Can't you use Julian dates for this? It is well defined (though conversion to normal dates may not be that far back) and should be easy to work with. (There may be problems if you go back so far that you need to worry about days not really being 24 hours long.) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Making serial survive pg_dump
I think that when SERIAL is used, the sequence should be tied inextricably to the table which created it, and it should be hidden from use for other purposes (perhaps similar to the way a toast table is). If you *want* to use a sequence across several tables, then you don't use SERIAL, you create a sequence. Agreed. Maybe an extra column in pg_attribute or something? Since no other sequence will depend on a column, I could base it on that. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Non-standard feature request
On Fri, 14 Jun 2002, Mike Mascari wrote: That is what I want to do, except by extending the grammar. I must admit to actually being surprised that a TEMP table created inside a transaction lived after the transaction completed. That's when I looked at the standard and saw that PostgreSQL's implementation was correct. I would think for most people session-long temp tables are more the exception than the rule. But I guess SQL92 doesn't think so. Regardless, a couple of other people have shown some interest in the idea. I'll post it to general as well as Tom suggests... Actually, we needed to use temp tables that live beyond the transaction, because there are no session variables in postgres. So I did an implementation that used temp tables instead. Having the temp table not live for the life of the session would be a big problem for me. -rocco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Breakage in crypt.c
Tom Lane wrote: There are various paths of control in md5_crypt_verify that do if (passwd) pfree(passwd); if (valuntil) pfree(valuntil); Isn't this now pfree'ing part of the saved pre-parsed pg_pwd data? Oops, yep. Fixed. The pfree's were fine in 7.2, but now, we cache pg_pwd. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] FEATURE REQUEST - More dynamic date type?
On Thu, 2002-06-13 at 16:39, Chris McCormick wrote: ... THE BACKGROUND - I am creating a web site where people can study the humanities. They can upload, discuss, and peer-review information. They can also create, edit, approve, and delete records in a postgresql db, using web forms. Many of these forms need a way to enter historical dates - a person DOB, the date an empire was founded, the date a book was published, etc. MY PROBLEM - Because this site deals with, among other things, ancient art, acheaology, and anthropology, I need a way to handle dates as specific as a single day, and as far back as 100,000 BC. According to the docs (I looked at http://www.postgresql.org/idocs/index.php?datatype-datetime.html), the farthest back any date type reaches is 4713 BC. So far, I have tried to deal with this problem by creating a numeric field for the year, and radio buttons for AD/BC. I then do a lot of form validation. Not only that, if I want to be as specific as a month or a day, then those are separate fields on my forms. Plus, I can't combine all of the fields and put them into a pg data type, because once again, they don't extend that far back. So, I have to maintain and validate the year, month, and days fields separately. Then imagine what I have to do if a user wants to _sort_ by date, or select events by date range! Ideally, I would like to figure this out on two fronts. I'd like to find out what's the best way to store dates that far back (with pg), and then on the PHP end I'll have to figure out how to parse entry so that it is as simple as possible for the end user. Knowing how to store these ancient dates in pg would help me a great deal. There are a lot of university and hobby sites out there working on digitizing collections of ancient texts, artifacts, etc. I don't know how the date range is chosen for a type like timestamp (4713BC - 1,465,001 AD), but it seems to me that there would be way more people working on recording the past (and thereby needed a date range that extends into ancient civilization) than working with dates in the far future (more than a million years ahead???). I hope that someone will be kind enough to reply with some ideas, or even to take up the cause and consider a date type that could be used for historical purposes. I am an avid fan of open source and pg, especially as compared to mySQL. I hope to continue using pg, and build a first-class web site that may one day serve as a great working example of what pg can do. Any help would be greatly appreciated. I have seen an implementation to deal with this problem; it was in a museum package developed in New Zealand which I saw about 7 years ago. I can't now remember what it was called, but it allowed objects to be catalogued with fuzzy dates. (The package was written in Revelation, which was a PICK-like database.) I think that the solution will have to be to develop a special type. Your fields have to hold dates that vary from very specific (4th August 1914) or quite close (1520 AD) to pretty vague (Louis Quatorze, 850-880, ca.1230, 5th century BC) or even very vague (4th Dynasty, Paleolithic). The good news is that PostgreSQL will let you do this, if you can devise the algorithms; I'm not sure if there's another RDBMS that would. Your type would need a flag byte to determine the type of date or period (I think 256 different types of date/period might be enough, but you could give it 2 bytes if you wanted to be sure(?) never to run out) and a value field -- integer or long integer. You would have to define comparison routines for sorting, equality and inclusion or intersection (1540 is included in 16th century, Napoleonic intersects 18th century and 19th Century). If you like this idea, I might be interested in developing it, in my infrequent moments of spare time... -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Cease from anger, and forsake wrath; do not fret- it leads only to evil.Psalms 37:8 signature.asc Description: This is a digitally signed message part
[HACKERS] Patches for LOCALTIME and regexp, feature list
I've just committed changes to include an SQL99 feature list as an appendix in the User's Guide. While preparing that I noticed a feature or two which would be trivial to implement, so we now have LOCALTIME and LOCALTIMESTAMP function calls per spec (afaict; the spec is very vague on the behaviors). I've also removed the ODBC-compatible parentheses on CURRENT_TIMESTAMP etc and made sure that the ODBC driver handles the case correctly. More details from the CVS logs are below... - Thomas Add LOCALTIME and LOCALTIMESTAMP functions per SQL99 standard. Remove ODBC-compatible empty parentheses from calls to SQL99 functions for which these parentheses do not match the standard. Update the ODBC driver to ensure compatibility with the ODBC standard for these functions (e.g. CURRENT_TIMESTAMP, CURRENT_USER, etc). Include a new appendix in the User's Guide which lists the labeled features for SQL99 (the labeled features replaced the basic, intermediate, and advanced categories from SQL92). features.sgml does not yet split this list into supported and unsupported lists. Search the existing regular expression cache as a ring buffer. Will optimize the case for repeated calls for the same expression, which seems to be the most common case. Formerly, always searched from the first entry. May want to look at the least-recently-used algorithm to make sure it is identifying the right slots to reclaim. Seems silly to do math when it seems that we could simply use an incrementing counter... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Queries using rules show no rows modified?
Has this been resolved and patched? --- Tom Lane wrote: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
