As I mentioned in my original post, I don't want to use citext or lower().
I tested on Windows, but as I mentioned in one of my first posts, collation
and case sensitivity are separate things.
With this, we are back at the beginning of the circle, so I'll leave it
there.
Maybe I'll check back in
Marcel van Pinxteren, 21.01.2013 13:22:
As I mentioned in my original post, I don't want to use citext or lower().
Why not for the unique index/constraint?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Mon, Jan 21, 2013 at 5:22 AM, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
As I mentioned in my original post, I don't want to use citext or lower().
I tested on Windows, but as I mentioned in one of my first posts, collation
and case sensitivity are separate things.
Wait, is
To be honest, the reason I don't want to use citext and lower(), is me
being lazy. If I have to use these features, there is more work for me
converting from SQL Server to Postgresql. I have to make more changes to my
database, and more to my software.
But, developers are generally lazy, so you
On 21 January 2013 17:25, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
The other reason, is that I assume that lower() adds overhead, so makes
things slower than they need to be.
Whether that is true, and if that is a compelling reason, I don't know.
Case insensitive collation
On Mon, Jan 21, 2013 at 9:25 AM, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
To be honest, the reason I don't want to use citext and lower(), is me being
lazy. If I have to use these features, there is more work for me converting
from SQL Server to Postgresql. I have to make more
Scott Marlowe wrote:
Honestly as a lazy DBA I have to say it'd be pretty easy to write a
script to convert any unique text index into a unique text index with
a upper() in it. As another poster added, collation ain't free
either. I'd say you should test it to see. My experience tells me
that
Marcel van Pinxteren wrote on 21.01.2013 17:25:
The other reason, is that I assume that lower() adds overhead
It won't add any noticeable overhead for the unique index.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Mon, Jan 21, 2013 at 1:45 PM, Scott Marlowe scott.marl...@gmail.com wrote:
On Mon, Jan 21, 2013 at 9:25 AM, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
To be honest, the reason I don't want to use citext and lower(), is me being
lazy. If I have to use these features, there is
On 2013-01-16, Marcel van Pinxteren marcel.van.pinxte...@gmail.com wrote:
--90e6ba6140da259e8204d36d0fa3
Content-Type: text/plain; charset=ISO-8859-1
From the Microsoft site I learned
http://msdn.microsoft.com/en-us/library/ms188046(v=sql.105).aspx
that they combine collation and
Desired behaviour:
1. If there is a row with 'ABC' (in a unique column) in the table, a row
with 'abc' should not be allowed
2. If I do SELECT * FROM aTable WHERE aColumn = 'ABC', I should see a row
with 'abc' as well (if there is one in the table)
This has been described in this mailing list a
You could look into running the DB on an OS that does support case
insensitive collation. It'll likely perform better too.
On 16 January 2013 20:40, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
From the Microsoft site I learned
Marcel van Pinxteren, 18.01.2013 14:13:
Desired behaviour:
1. If there is a row with 'ABC' (in a unique column) in the table, a row with
'abc' should not be allowed
That's an easy one:
create unique index on foo (lower(the_column));
--
Sent via pgsql-general mailing list
On Fri, Jan 18, 2013 at 6:13 AM, Marcel van Pinxteren
marcel.van.pinxte...@gmail.com wrote:
Desired behaviour:
1. If there is a row with 'ABC' (in a unique column) in the table, a row
with 'abc' should not be allowed
2. If I do SELECT * FROM aTable WHERE aColumn = 'ABC', I should see a row
The subject has been discussed on this mailing list before, recently.
To be able to switch from SQL Server to Postgresql, for me this is
essential.
Therefore the question: are there plans to create a set of case
insensitive, and maybe also accent insensitive collations in the near
future?
I have
Marcel van Pinxteren marcel.van.pinxte...@gmail.com writes:
Therefore the question: are there plans to create a set of case
insensitive, and maybe also accent insensitive collations in the near
future?
Not from the Postgres project -- we just use the collations supplied by
the operating
From the Microsoft site I learned
http://msdn.microsoft.com/en-us/library/ms188046(v=sql.105).aspx
that they combine collation and ComparisonStyle to a collation name.
I thought that case insensitivity had to be built into the collation, but
apparently MS built case sensitivity in the database
17 matches
Mail list logo
