Re: [HACKERS] [pgsql-www] PGFoundry down?

2006-10-28 Thread Devrim GUNDUZ
Hi, On Sat, 2006-10-28 at 01:27 -0400, Jonah H. Harris wrote: PGFoundry is responding with: PgFoundry Could Not Connect to Database: Marc is already working on it. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development,

[HACKERS] PGFoundry down?

2006-10-28 Thread Jonah H. Harris
PGFoundry is responding with: PgFoundry Could Not Connect to Database: -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830|

Re: [HACKERS] bug in on_error_rollback !?

2006-10-28 Thread Gurjeet Singh
On 10/27/06, Peter Eisentraut [EMAIL PROTECTED] wrote: In psql, the psqlparts follow the syntax rules of psql, the SQL parts follow the syntaxrules of SQL.The syntax rules of psql in turn are inspired by Unixshells, sort of because psql is used that way.(Surely one wouldn't want the argument to \i

Re: [HACKERS] bug in on_error_rollback !?

2006-10-28 Thread Richard Troy
Gurjeet, I see that the question of case sensitivity in psql is still being discussed. I don't have a dog in that fight, but thought I might make a suggestion. To wit: I propose you adopt the standard that I personally have adopted eons ago - literally perhaps 20 years ago - and has by now

Re: [HACKERS] bug in on_error_rollback !?

2006-10-28 Thread Robert Treat
On Friday 27 October 2006 09:19, Greg Sabino Mullane wrote: This is documented clearly on the psql man page, so it is simply not a bug, and changing this would probably break lots of legacy scripts. In a general sense, perhaps, but in this *particular* case, I don't see what harm allowing

Re: [HACKERS] bug in on_error_rollback !?

2006-10-28 Thread Gurjeet Singh
On 10/29/06, Richard Troy [EMAIL PROTECTED] wrote: ALWAYS presume case sensitivity and code _exactly_ thatway every time. That makes a lot of sense for a C/C++/Java/(any other case-sens. lang.) developer. And perhaps SQL developers too should adopt it; but sadly (for nay sayers), the SQL standard