On Fri, Oct 27, 2006 at 01:19:25PM -, 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
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
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
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
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
--On Freitag, Oktober 27, 2006 11:00:07 +0530 Gurjeet Singh
[EMAIL PROTECTED] wrote:
I was thinking of recommending this to someone, but wanted to try it on
my own first; good thing that I did. I think it is broken as of now.
I assume that the error thrown for 'select 1', inside a
Thanks ...but case-sensitivity (even without quotes or d-quotes) is the last thing I'd expect in a SQL compliant software. This was highly unexpected. May I dare to raise a bug to eliminate case-sensitivity in psql variables? Will I get support from the community?
Regards,-- [EMAIL
Gurjeet Singh wrote:
Thanks ...
but case-sensitivity (even without quotes or d-quotes) is the last thing
I'd
expect in a SQL compliant software. This was highly unexpected. May I dare
to raise a bug to eliminate case-sensitivity in psql variables? Will I get
support from the community?
I understand that psql commands are not SQL, but since psql is used to interact with SQL database, then the assumption of case-insensitivity in psql also comes naturally to the user.\ds and \dS are commands (first token on the line) so it is acceptable that they be case-sensitive. But a command's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 Fri, 2006-10-27 at 03:50 -0500, Andrew Dunstan wrote:
psql variables and commands are not SQL, and are case sensitive. For
example, \ds and \dS are not at all the same.
This is documented clearly on the psql man page, so it is simply not a
bug
It may be documented, but \set still has a
Gurjeet Singh wrote:
\ds and \dS are commands (first token on the line) so it is
acceptable that they be case-sensitive. But a command's
parameters/arguments should not be case sensitive, unless quoted.
This distinction has not basis in SQL syntax.
If it is documented that psql commands are
12 matches
Mail list logo
