On 12/5/06, Ken Johanson [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Tom Lane wrote:
The real bottom line, though, is that this community has little respect
for proposals that involve moving away from the SQL spec rather than
closer to it; and that's what you're asking us to do. The
Bruce Momjian wrote:
Tom Lane wrote:
The real bottom line, though, is that this community has little respect
for proposals that involve moving away from the SQL spec rather than
closer to it; and that's what you're asking us to do. The spec is not
at all vague about the case-sensitivity of
Martijn van Oosterhout wrote:
I think you're missing the point that clients will be using languages
that are case sensetive. Consider the following Perl code:
$dbh-do(CREATE TEMP TABLE foo (Bar int4));
$dbh-do(INSERT INTO foo VALUES (1));
my $sth = $dbh-prepare(SELECT Bar FROM foo);
Tom Lane wrote:
Ken Johanson [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I think it's unlikely to happen anytime soon. The primary reason being
that then you can no longer use indexes to search the catalog. Which
I take a different opinion on this:
-*If* the option to
Martijn van Oosterhout wrote:
On Sat, Dec 02, 2006 at 12:41:37AM -0700, Ken Johanson wrote:
1: It seems like this behavior of case sensitive-or-not-identifiers
could/should be a config option -- either globally for the server,
database, or at the connection/session level. Other databases *do*
Ken Johanson skrev:
Has your experience with PG been different? If so I presume you have
have found a config that allows?:
SELECT
pers.firstName,
pers.lastname,
As long as you don't create the columns using quotes you can use that
kind of names. For example
CREATE TABLE foo (BAR int);
Dennis Bjorklund wrote:
Ken Johanson skrev:
Has your experience with PG been different? If so I presume you have
have found a config that allows?:
SELECT
pers.firstName,
pers.lastname,
As long as you don't create the columns using quotes you can use that
kind of names. For example
Ken Johanson skrev:
Although, since I'm using pgAdmin (III) to design tables in this case,
or creating the tables through JDBC (a convenient way to copy tables and
data from another datasource) (using the copy-paste gesture), I believe
those tools both *are* quoting identifiers that have
Dennis Bjorklund wrote:
So my vote would remain for having a config-option to ignore case,
even on quoted identifiers..
And my vote is to not have such an option. But I'm not the one who
decide so don't worry about what I think :-) I would like to have an
option to upper case the identifiers
Ken Johanson [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I think it's unlikely to happen anytime soon. The primary reason being
that then you can no longer use indexes to search the catalog. Which
I take a different opinion on this:
-*If* the option to turn on case-insenetive
Tom Lane wrote:
Ken Johanson [EMAIL PROTECTED] writes:
-*If* the option to turn on case-insenetive behavior were selectable at
the DB or session level, the existing apps could continue to use the
case sensitve mode and be completely unaffected.
Ken, you clearly fail to understand the point
Chuck McDevitt wrote:
At Teradata, we certainly interpreted the spec to allow case-preserving,
but case-insensitive, identifiers.
Users really liked it that way
My 2 thoughts:
1: It seems like this behavior of case sensitive-or-not-identifiers
could/should be a config option -- either
On Nov 14, 2006, at 2:42 PM, Simon Riggs wrote:
On Thu, 2006-11-02 at 10:51 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We have namespaces to differentiate between two sources of object
names,
so anybody who creates a schema where MyColumn is not the same
thing as
myColumn
: Monday, October 30, 2006 7:24 PM
To: beau hargis
Cc: pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
sensitivity?
beau hargis [EMAIL PROTECTED] writes:
Considering the differences that already exist between database
systems
as
entered by the user.
So, your example would work just fine.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, October 30, 2006 10:35 PM
To: Chuck McDevitt
Cc: beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case
10:35 PM
To: Chuck McDevitt
Cc: beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
sensitivity?
Chuck McDevitt [EMAIL PROTECTED] writes:
At Teradata, we certainly interpreted the spec to allow
case-preserving
]
Sent: Monday, October 30, 2006 10:35 PM
To: Chuck McDevitt
Cc: beau hargis; pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
sensitivity?
Chuck McDevitt [EMAIL PROTECTED] writes:
At Teradata, we certainly interpreted
PROTECTED]
Sent: Tuesday, October 31, 2006 10:38 PM
To: Chuck McDevitt
Cc: Stephan Szabo; beau hargis; pgsql-sql@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
Chuck McDevitt [EMAIL PROTECTED] writes:
Equivalent, yes. But I can
On Wed, 2006-11-01 at 11:31 -0500, Chuck McDevitt wrote:
But, stepping back from all that, what is it the users want?
1) When re-creating a CREATE TABLE statement from whatever catalog
info, they'd like the names to come back exactly as then entered them.
If I do:
CREATE
Simon Riggs [EMAIL PROTECTED] writes:
We have namespaces to differentiate between two sources of object names,
so anybody who creates a schema where MyColumn is not the same thing as
myColumn is not following sensible rules for conceptual distance.
I'd agree that that is not a good design
On Tue, 31 Oct 2006, Chuck McDevitt wrote:
We treated quoted identifiers as case-specific, as the spec requires.
In the catalog, we stored TWO columns... The column name with case
converted as appropriate (as PostgreSQL already does), used for looking
up the attribute,
And a second column,
Chuck McDevitt [EMAIL PROTECTED] writes:
Equivalent, yes. But I can interpret that clause it mean I can show
either the case folded or non-case-folded value in the information
schema, as they are equivalent.
Well, that's an interesting bit of specs-lawyering, but I don't see
how you can
Chuck McDevitt [EMAIL PROTECTED] writes:
At Teradata, we certainly interpreted the spec to allow case-preserving,
but case-insensitive, identifiers.
Really?
As I see it, the controlling parts of the SQL spec are (SQL99 sec 5.2)
26) A regular identifier and a delimited identifier are
23 matches
Mail list logo
