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, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/




signature.asc
Description: This is a digitally signed message part


[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| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


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 be case-insensitive?)A very good reasoning... I completely agree...But you'd also agree that since the psql variables can (and most often they are) used in SQL satements, we should consider making atleast \set case insensitive! 
postgres=# \set x 1postgres=# select :x;
?column?--
 1(1 row)
postgres=# select :X;
ERROR: syntax error at or near :LINE 1: select :X;
 ^postgres=#
Gregwhat harm allowing \set on_error_rollback would be: it certainlywon't break any existing scripts I wrote this feature (but someone elsechose the name!) and I still occasionally write it lowercase and wonder
why it isn't working. :)/Greg I agree, we can't make every '\' command case-insensitive, but a few, where it makes absolute sense, should be subject to reconsideration. We have the choice of making it more user-friendly, and less confusing.
-- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com


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 saved me many days of
time, I'm sure; ALWAYS presume case sensitivity and code _exactly_ that
way every time. (And develop you're own capitalization standard, too, so
you'll always know which way it goes.) You'll never be disappointed that
way and you won't create hidden bugs. If you want to keep arguing that
Postgres should change to meet your expectations, fine, and if it changes,
great for you, but you'll just have the same problem someday with some
other package - better you change your habits instead!

Richard

On Sat, 28 Oct 2006, Gurjeet Singh wrote:

 Date: Sat, 28 Oct 2006 20:01:00 +0530
 From: Gurjeet Singh [EMAIL PROTECTED]
 To: Peter Eisentraut [EMAIL PROTECTED]
 Cc: pgsql-hackers@postgresql.org, Andrew Dunstan [EMAIL PROTECTED],
  Bernd Helmle [EMAIL PROTECTED]
 Subject: Re: [HACKERS] bug in on_error_rollback !?

 On 10/27/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
 
  In psql, the psql
  parts follow the syntax rules of psql, the SQL parts follow the syntax
  rules of SQL.  The syntax rules of psql in turn are inspired by Unix
  shells, sort of because psql is used that way.  (Surely one wouldn't
  want the argument to \i be case-insensitive?)


 A very good reasoning... I completely agree...

 But you'd also agree that since the psql variables can (and most often they
 are) used in SQL satements, we should consider making atleast \set case
 insensitive!

 postgres=# \set x 1
 postgres=# select :x;
  ?column?
 --
 1
 (1 row)

 postgres=# select :X;
 ERROR:  syntax error at or near :
 LINE 1: select :X;
^
 postgres=#

 Greg
 what harm allowing \set on_error_rollback would be: it certainly
 won't break any existing scripts.
 ...
 I wrote this feature (but someone else
 chose the name!) and I still occasionally write it lowercase and wonder
 why it isn't working. :)
 /Greg

 I agree, we can't make every '\' command case-insensitive, but a few,
 where it makes absolute sense, should be subject to reconsideration. We have
 the choice of making it more user-friendly, and less confusing.





-- 
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
[EMAIL PROTECTED], http://ScienceTools.com/


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


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 \set on_error_rollback would be: it certainly
 won't break any existing scripts. I wrote this feature (but someone else
 chose the name!) and I still occasionally write it lowercase and wonder
 why it isn't working. :)

 Perhaps even allowing all of the \set commands to be case-insensitive
 may be a good idea?

\typo

;-)

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


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 doesn't require them to (and for good reason); and as is said in the PG community very often, 'who are we to question the standard?'.
(And develop you're own capitalization standard, too, soyou'll always know which way it goes.) You'll never be disappointed that
way and you won't create hidden bugs.I'd be at the losing end all the time that way; 'coz every package has it's own coding style, (take PG for example), and I'd hate to see myself, or anyone else, to dirty the code by using a new, although consistent in itself, coding style. In a package developed in a case-sensitive language, I'd always want to code the way the earlier devils (I mean devels) had.
Seems like its time to crawl back under my rock. -- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com