On Tue, 2016-01-26 at 11:06 +, Max wrote:
> Is there a collation for case and accent insensitive filter? I just
> found the use of operators like ILIKE ou CITEXT module but I can't
> use ILIKE in the queries and the CITEXT is a field-by-field solution
> for the case insensitive part of the prob
Is there a collation for case and accent insensitive filter? I just found the
use of operators like ILIKE ou CITEXT module but I can't use ILIKE in the
queries and the CITEXT is a field-by-field solution for the case insensitive
part of the problem. I also found the unaccent text search dictiona
On Thu, Dec 12, 2013 at 12:47 PM, Dev Kumkar wrote:
> + hackers
>
>
>
> On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar wrote:
>
>> On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
>>
>>> Actually for searches lower will work.
>>> But the other important aspect is 'inserts' which would result 2 row
+ hackers
On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar wrote:
> On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
>
>> Actually for searches lower will work.
>> But the other important aspect is 'inserts' which would result 2 rows if
>> the values are 'A' and 'a'. Intent here to have it case in
On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
> Actually for searches lower will work.
> But the other important aspect is 'inserts' which would result 2 rows if
> the values are 'A' and 'a'. Intent here to have it case insensitive.
>
> If CITEXT it will update the same row and works.
> CITE
Actually for searches lower will work.
But the other important aspect is 'inserts' which would result 2 rows if
the values are 'A' and 'a'. Intent here to have it case insensitive.
If CITEXT it will update the same row and works.
CITEXT is an alternative but was wondering if there is any other alt
On Wed, Dec 11, 2013 at 04:55:07PM +0530, Dev Kumkar wrote:
> creating database. I have been looking at other discussions and doesn't
> look like anything of that coming up soon that makes database case
> insensitive.
You could build lower() indexes on any column you want to search CI
and lower()
Can case-insensitive collation help here?
On Wed, Dec 11, 2013 at 4:55 PM, Dev Kumkar wrote:
> Thanks John.
>
> Yes CITEXT would work, the only thing its needs DDL changes across and
> hence was looking for any such global database parameter setting while
> creating database. I have been lookin
Thanks John.
Yes CITEXT would work, the only thing its needs DDL changes across and
hence was looking for any such global database parameter setting while
creating database. I have been looking at other discussions and doesn't
look like anything of that coming up soon that makes database case
inse
On 12/10/2013 10:31 PM, Dev Kumkar wrote:
I know about CITEXT data type, but what am looking for is if there any
parameter at database level which just makes the database case
insensitive.
there's nothing that will do that in postgres.
whats wrong with using CITEXT ?
--
john r pierce
How to create case insensitive database?
I know about CITEXT data type, but what am looking for is if there any
parameter at database level which just makes the database case insensitive.
I mean both values 'ABC' and 'abc' are treated same for inserts and also
all the comparisons by default are c
>> But in the following expression:
>>
>> template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END;
>> ERROR: division by zero
>>
>> (Just to be sure, a "SELECT (SELECT 0)=0;" returns true)
>>
>> It seems that when the "CASE WHEN expression" is a query, the evaluation
>> order changes.
>> Acc
Andrea Lombardoni wrote:
> It gets even stranger:
>
> template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/(select 0) END;
> case
> --
> 0
> (1 row)
>
> Here it seems that the ELSE does not get evaluated (which is correct).
Yes, of course, because both subselects will not get evaluat
On Mon, Jun 17, 2013 at 11:11 PM, Stefan Drees wrote:
>
> pg924=# SELECT CASE WHEN 1 != 1 THEN 1/0 ELSE ((SELECT 1)=1)::integer END;
> case
> --
> 1
> (1 row)
>
> here the 1/0 is happily ignored.
>
It gets even stranger:
template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/(select
Stefan Drees wrote:
> On 2013-06-17 22:17 +02:00, Andrea Lombardoni wrote:
>> I observed the following behaviour (I tested the following statements in
>> 9.0.4, 9.0.5 and 9.3beta1):
>>
>> $ psql template1
>> template1=# SELECT CASE WHEN 0=0 THEN 0 ELSE 1/0 END;
>> case
>> --
>> 0
>> (1
On 2013-06-17 22:17 +02:00, Andrea Lombardoni wrote:
I observed the following behaviour (I tested the following statements in
9.0.4, 9.0.5 and 9.3beta1):
$ psql template1
template1=# SELECT CASE WHEN 0=0 THEN 0 ELSE 1/0 END;
case
--
0
(1 row)
template1=# SELECT CASE WHEN 1=0 THEN 0 E
I observed the following behaviour (I tested the following statements in
9.0.4, 9.0.5 and 9.3beta1):
$ psql template1
template1=# SELECT CASE WHEN 0=0 THEN 0 ELSE 1/0 END;
case
--
0
(1 row)
template1=# SELECT CASE WHEN 1=0 THEN 0 ELSE 1/0 END;
ERROR: division by zero
In this case the C
"Gauthier, Dave" writes:
> thedb=# select
> ||bicolumn||,
> coalesce(permitted_values,'is_null'),
> case permitted_values when NULL then 'null' else
> ||permitted_values|| end
>from bi_constraints limit 2;
That's equivalent to "case when permitted_values = NULL then ...
v9.0.1 on linux
thedb=# select
||bicolumn||,
coalesce(permitted_values,'is_null'),
case permitted_values when NULL then 'null' else ||permitted_values||
end
from bi_constraints limit 2;
?column?| coalesce| case
+---+
2013/2/16 Glenn Pierce :
> Hi
>
> Does anyone know how one would
> select from a table with a hstore field treating the key of the hstore as
> case insensitive.
>
> ie
>
> SELECT id, lower(additional_info->'type') AS type FROM table
>
> I would like this to work even if if the store tyoe is
>
> 'Ty
Hi
Does anyone know how one would
select from a table with a hstore field treating the key of the hstore as
case insensitive.
ie
SELECT id, lower(additional_info->'type') AS type FROM table
I would like this to work even if if the store tyoe is
'Type' -> 'original'
failing that is there a wa
On Mon, Jan 21, 2013 at 1:45 PM, Scott Marlowe wrote:
> On Mon, Jan 21, 2013 at 9:25 AM, Marcel van Pinxteren
> 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
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:
http://www.
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
>
On Mon, Jan 21, 2013 at 9:25 AM, Marcel van Pinxteren
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 changes to my database,
> a
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 co
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 cou
On Mon, Jan 21, 2013 at 5:22 AM, Marcel van Pinxteren
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 there an actual reason for n
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:
http://www.postgresql.or
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 a
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
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 (pgsql-general@p
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
> http://msdn.microsoft.com/en-us/library/ms18804
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 fe
On 2013-01-16, Marcel van Pinxteren 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 "ComparisonStyle" to a collation nam
>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
Marcel van Pinxteren 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 system.
r
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 n
On 09/01/2012 02:07 PM, Thalis Kalfigkopoulos wrote:
Thanks all for the replies. Actually I had already tested that sum()
behaved correctly with respect to NULLs, meaning that it ignored them
(or treated them as 0, couldn't really tell). That's why I went ahead
sum()ing even though I knew NULLs w
On 2012-09-01, Chris Angelico wrote:
> On Sat, Sep 1, 2012 at 12:07 PM, David Johnston wrote:
>> These are not equivalent if some values of foo are not-null and you want the
>> sum of all non-null values while replacing any nulls with zero. So the
>> decision depends on what and why you are su
On Sat, Sep 1, 2012 at 6:19 AM, David Johnston wrote:
> On Aug 31, 2012, at 22:49, Tom Lane wrote:
>
>> David Johnston writes:
>>> On Aug 31, 2012, at 21:52, Tom Lane wrote:
David Johnston writes:
> That said you might want to try
> SUM(COALESCE(foo, 0))
>>
Actually I'd go wi
On Aug 31, 2012, at 22:49, Tom Lane wrote:
> David Johnston writes:
>> On Aug 31, 2012, at 21:52, Tom Lane wrote:
>>> David Johnston writes:
That said you might want to try
SUM(COALESCE(foo, 0))
>
>>> Actually I'd go with "COALESCE(SUM(foo), 0)" since that requires only
>>> one COAL
David Johnston writes:
> On Aug 31, 2012, at 21:52, Tom Lane wrote:
>> David Johnston writes:
>>> That said you might want to try
>>> SUM(COALESCE(foo, 0))
>> Actually I'd go with "COALESCE(SUM(foo), 0)" since that requires only
>> one COALESCE operation, not one per row.
> These are not equiv
On Sat, Sep 1, 2012 at 12:07 PM, David Johnston wrote:
> These are not equivalent if some values of foo are not-null and you want the
> sum of all non-null values while replacing any nulls with zero. So the
> decision depends on what and why you are summing.
It comes to the same result with SU
On Aug 31, 2012, at 21:52, Tom Lane wrote:
> David Johnston writes:
>> On Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos wrote:
>>> This didn't work as expected (the NULL's persisted):
>>> ...CASE sum(foo) WHEN NULL THEN 0 ELSE sum(foo) END...
>
>> Guessing this form effectively evaluates to
>
David Johnston writes:
> On Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos wrote:
>> This didn't work as expected (the NULL's persisted):
>> ...CASE sum(foo) WHEN NULL THEN 0 ELSE sum(foo) END...
> Guessing this form effectively evaluates to
> WHEN sum(foo) = NULL instead of IS NULL and thus the
On Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos wrote:
> Hello all,
>
> I have a query that presents a sum() where in some records it's NULL
> because all members of the group are NULL.
> I decided I wanted to see a pretty 0 instead of NULL since it fits the
> logic of the app.
>
> This didn't
Hello all,
I have a query that presents a sum() where in some records it's NULL
because all members of the group are NULL.
I decided I wanted to see a pretty 0 instead of NULL since it fits the
logic of the app.
This didn't work as expected (the NULL's persisted):
...CASE sum(foo) WHEN NULL THEN
On Mon, Jun 06, 2011 at 10:24:45PM +0200, Heine Ferreira wrote:
> I basicically want to avoid using upper in comparisons.
> Has anyone tried this?
> Do you know if this will work?
There's a contrib module that will allow you to do this. See the
citext datatype.
A
--
Andrew Sullivan
a...@crank
On Mon, Jun 6, 2011 at 2:24 PM, Heine Ferreira wrote:
> Hi
>
> I posted a similar question before. I was told that Postgres is always case
> sensitive.
> I was actually referring to text data not identifiers.
> I mean char and varchar fields.
> I basicically want to avoid using upper in comparison
Hi
I posted a similar question before. I was told that Postgres is always case
sensitive.
I was actually referring to text data not identifiers.
I mean char and varchar fields.
I basicically want to avoid using upper in comparisons.
With some databases you can use a utf8 characterset and a unicode
From: Peter Geoghegan
Subject: Re: [GENERAL] Case Insensitive Foreign Key Constraint
I would probably just have a check constraint that prevented the
relevant PK field from being lower case in the first place. I had to
do that recently, but my approach reflected the business rules.
This is
I would probably just have a check constraint that prevented the
relevant PK field from being lower case in the first place. I had to
do that recently, but my approach reflected the business rules.
You may prefer to use citext:
http://www.postgresql.org/docs/current/interactive/citext.html
--
R
Hi all,
Is there a way to have text-type foreign keys be case insensitive?
development=# CREATE TABLE foo (foo text PRIMARY KEY);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for
table "foo"
CREATE TABLE
development=# INSERT INTO foo VALUES ('foo');
INSERT 0 1
dev
On Thu, Jan 13, 2011 at 03:29:03PM -, Phillip Smith wrote:
> modifying user inputted data is not an option for me. I need to
> maintain the original data. I had read about indexing on a lower
> function. This all seems a bit of a bodgy workaround to me. A clean
> Case Insensitive collation set
2011/1/13 Phillip Smith :
> Thanks Pavel,
>
> Is this the only way?. I would prefer to use a collation setting if this is
> possible. Do you know whether there would be a performance hit using non
> standard character strings?
It is preferred way. PostgreSQL doesn't support a collations, and what
Hi Karsten,
modifying user inputted data is not an option for me. I need to maintain the
original data. I had read about indexing on a lower function. This all seems a
bit of a bodgy workaround to me. A clean Case Insensitive collation setting is
cleaner. Is this supported in postgreSQL 9?
R
Thanks Pavel,
Is this the only way?. I would prefer to use a collation setting if this is
possible. Do you know whether there would be a performance hit using non
standard character strings?
Phillip
> you should to use a citext datatype
>
> http://www.postgresql.org/docs/9.0/interactive/citext.html
Or:
- use a functional index with lower() to ensure uniqueness
- use a BEFORE trigger to lower() the inserted data
Karsten
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Fl
Hello
you should to use a citext datatype
http://www.postgresql.org/docs/9.0/interactive/citext.html
regards
Pavel Stehule
2011/1/13 Phillip Smith :
> Hi,
> I'm moving over from MS SQL. I've been googling this for ages now and
> suprisingly cannot find a clear answer.
>
> I want my data in tab
Hi,
I'm moving over from MS SQL. I've been googling this for ages now and
suprisingly cannot find a clear answer.
I want my data in tables to be case insensitive.
This is so i can:
1. Put keys on natural key fields, for instance a product part number. I
product number 'ABC123' inserted i need
Hello
try to explicit cast
select 't'::boolean;
regards
Pavel Stehule
2009/10/14 Gus Waddell :
> Hi everyone,
>
> I am currently working on an app that is split into several databases with
> the same table but a column with differing data type.
>
> eg. Database 1
> tablename: gp
> column: avai
Hi everyone,
I am currently working on an app that is split into several databases
with the same table but a column with differing data type.
eg. Database 1
tablename: gp
column: available - data type boolean
Database 2
tablename: gp
column: available - data type character(1)
I would lik
*De:* John R Pierce
*Para:* Will Rutherdale (rutherw)
*Cc:* pgsql-general@postgresql.org
*Enviadas:* Terça-feira, 24 de Março de 2009 17:21:20
*Assunto:* Re: [GENERAL] Case sensitivity problems with user name
Will Rutherdale (rutherw) wrote:
> When I try going into psql as user postg
On 24/03/2009 20:25, Berdam wrote:
> aer
>
?
--
Raymond O'Donnell, Director of Music, Galway Ca
On 24/03/2009 20:38, Will Rutherdale (rutherw) wrote:
> Pardon my newness to Postgres.
We've all been there at some point! - except of course for Tom Lane.
:-)
Ray.
--
Raymond O'Donnell, Director of Music, Galway Cathedral, Irelan
herdale (rutherw)
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Case sensitivity problems with user name
Will Rutherdale (rutherw) wrote:
> When I try going into psql as user postgres to change the user name, I
> get this problem:
>
> postgres=# alter user mickey rename to
@postgresql.org
Enviadas: Terça-feira, 24 de Março de 2009 17:21:20
Assunto: Re: [GENERAL] Case sensitivity problems with user name
Will Rutherdale (rutherw) wrote:
> When I try going into psql as user postgres to change the user name, I get
> this problem:
>
> postgres=# alter user mick
Will Rutherdale (rutherw) wrote:
When I try going into psql as user postgres to change the user name, I
get this problem:
postgres=# alter user mickey rename to Mickey;
ERROR: role “mickey” already exists
you might try...
alter user "mickey" rename to "Mickey";
--
Sent via pgsql-genera
Hi.
I have a little problem with user names and Postgres commands.
Due to quirks in corporate account management using ADS, some user names
come out as, say, Mickey when you log into Linux instead of mickey.
This unfortunate user tries to run Postgres commands and gets for
instance:
$ p
Kevin Murphy writes:
> I've noticed that the argument to the \c (connect) meta-command is
> case-sensitive. This doesn't seem to be consistent with other
> meta-commands or the SQL standard of case-insensitive identifiers.
... however, it's consistent with the behavior of psql's equivalent
c
I've noticed that the argument to the \c (connect) meta-command is
case-sensitive. This doesn't seem to be consistent with other
meta-commands or the SQL standard of case-insensitive identifiers.
Would it hurt to change the behavior?
Regards,
Kevin Murphy
--
Sent via pgsql-general mailing
Jason Long wrote:
> Is there any way to have Postgres preserve the case of tables and column
> names in queries without having to use quotes for columns with mixed case?
No.
PostgreSQL folds to lower-case (the SQL standard specifies upper-case
iirc) to provide case-insensitivity.
--
Richard H
Is there any way to have Postgres preserve the case of tables and column
names in queries without having to use quotes for columns with mixed case?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Thomas Finneid wrote:
> I have a case sensitivity problem I dont understand.
>
> On a Solaris 10 with pg 8.2.6 (Sun build) I get problems when I do a
> CREATE DATABASE with a db name with case.
>
> On a Kubuntu machine with pg 8.2.7 it is not a problem.
>
> More specifically the problem arises a
I have a case sensitivity problem I dont understand.
On a Solaris 10 with pg 8.2.6 (Sun build) I get problems when I do a
CREATE DATABASE with a db name with case.
On a Kubuntu machine with pg 8.2.7 it is not a problem.
More specifically the problem arises after the CREATE DATABASE, it
occurs
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> Still why does the else condition get evaluated anyway when at least
> one of the "when" condition is true?
Because 'literal'::type is a literal of that type; it does not represent
a run-time conversion. I think we document that under the discus
On Wed, Nov 26, 2008 at 04:17:40PM +0100, Ivan Sergio Borgonovo wrote:
> as a more self contained example:
>
> select case when ''='' then null else ''::timestamp end;
Tee hee, I've just realized what you're doing. You've got the cast in
the wrong place! Try:
select case when ''='' then null
On Wed, 26 Nov 2008 14:18:44 +
Sam Mason <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2008 at 02:53:07PM +0100, Ivan Sergio Borgonovo
> wrote:
> > case when ''=extinput then null else extinput::timestamp end
>
> I'd tend to use nullif(extinput,'')::timestamp for this sort of
Thanks it was on
On Wed, Nov 26, 2008 at 02:53:07PM +0100, Ivan Sergio Borgonovo wrote:
> case when ''=extinput then null else extinput::timestamp end
I'd tend to use nullif(extinput,'')::timestamp for this sort of thing.
It's not going to do anything much different from what you're doing, but
may end up evaluatin
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> I've
> case when ''=extinput then null else extinput::timestamp end
> now when extinput='' it seems that else extinput::timestamp get
> evaluated anyway and I get:
> invalid input syntax for type timestamp: ""
I think you are leaving off a large
I've
case when ''=extinput then null else extinput::timestamp end
now when extinput='' it seems that else extinput::timestamp get
evaluated anyway and I get:
invalid input syntax for type timestamp: ""
The purpose of all this gymnic would be to convert empty string to
null and everything else t
Garry Saddington wrote:
It does work but returns a column called case. How can I return the case
column as 'postcode'?
select
CASE WHEN postcode ilike '%OO%' THEN ''
END as postcode
from addresses
--
Guy Rouillier
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
>
> BTW, should you have an "else" clause in there? - What happens when the
> comparison fails?
>
As Tom said, a null value would be returned.
On 24/09/2008 23:22, Garry Saddington wrote:
>> Garry Saddington <[EMAIL PROTECTED]> writes:
>>> CASE WHEN postcode ilike '%OO%' THEN ''
>>> END
>>> from addresses
>
> It does work but returns a column called case. How can I return the case
> column as 'postcode'?
...case when postcode ilike '%OO
On Wed, Sep 24, 2008 at 3:22 PM, Garry Saddington
<[EMAIL PROTECTED]> wrote:
>> > select *,
>> > CASE WHEN postcode ilike '%OO%' THEN ''
>> > END
>> > from addresses
> It does work but returns a column called case. How can I return the case
> column as 'postcode'?
You have to give an Alias to thi
On Wednesday 24 September 2008 21:03, Tom Lane wrote:
> Garry Saddington <[EMAIL PROTECTED]> writes:
> > Can anyone tell me why this will not work?
> >
> > select *,
> > CASE WHEN postcode ilike '%OO%' THEN ''
> > END
> > from addresses
> > ...
>
> Define "not work". What are you expecting it to d
Garry Saddington <[EMAIL PROTECTED]> writes:
> Can anyone tell me why this will not work?
> select *,
> CASE WHEN postcode ilike '%OO%' THEN ''
> END
> from addresses
> ...
Define "not work". What are you expecting it to do versus what
really happens?
Right offhand it looks like the CASE will r
Can anyone tell me why this will not work?
select *,
CASE WHEN postcode ilike '%OO%' THEN ''
END
from addresses
where studentid=1234
and addresstype='C'
There are postcodes like this: OO00 0OO
Regards
Garry
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
On Wed, 3 Sep 2008, Fco. Mario Barcala Rodr?guez wrote:
Hi all:
Is there any way to create a case sensitive full text index? My target
is to make case sensitive full text searches but I don't know how.
I could create a configurario for full text searching:
CREATE TEXT SEARCH CONFIGURATION pub
Hi all:
Is there any way to create a case sensitive full text index? My target
is to make case sensitive full text searches but I don't know how.
I could create a configurario for full text searching:
CREATE TEXT SEARCH CONFIGURATION public.myconfiguration (PARSER =
pg_catalog.default);
CREATE
c k wrote:
Hi,
I want to create a function as follows:
case variable=value1
SQL statements
case variable=value2
SQL statements
case else
end of case
Looks like you want to use pl/pgsl and IF ... THEN ... ELSE instead?
Cheers
Tino
smime.p7s
Description: S/MIME Cryptographic Signature
Hi,
I want to create a function as follows:
case variable=value1
SQL statements
case variable=value2
SQL statements
case else
end of case
CPK
On Tue, Aug 19, 2008 at 5:17 PM, Bill Moran
<[EMAIL PROTECTED]>wrote:
> In response to "c k" <[EMAIL PROTECTED]>:
>
> > Is there any control structu
In response to "c k" <[EMAIL PROTECTED]>:
> Is there any control structure statement similar to select case ... ? If yes
> how to use it. I have tried to use, case when then
> end, but not worked well as I want to use other control structures and sql
> statements to be executed for each case.
P
Hello
Develop PL/pgSQL (PostgreSQL 8.4) has CASE statement. Actual and
older version hasn't nothing similar.
Regards
Pavel Stehule
2008/8/19 c k <[EMAIL PROTECTED]>:
> Is there any control structure statement similar to select case ... ? If yes
> how to use it. I have tried to use, case when t
Is there any control structure statement similar to select case ... ? If yes
how to use it. I have tried to use, case when then
end, but not worked well as I want to use other control structures and sql
statements to be executed for each case.
Please reply.
Thanks
CPK.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually I think the standard mandates case-folding (though to upper
> case rather than lower, i.e. the other way around)
That's how I read it too. SQL99 5.2 saith
22) The case-normal form of the of a is used for purposes such as and includi
Nico Sabbi wrote:
> yet I find disturbing that Postgres doesn't make the effort
> to respect the case specified by the user.
It does -- if you quote the names.
> If I created a field
> called "REF" why should Postgres call it "ref" in the output of queries
> if the standard doesn't specify any o
On Jan 18, 2008, at 1:14 PM, Nico Sabbi wrote:
Tom Lane ha scritto:
The SQL standard specifies that unquoted identifiers are case-
insensitive.
You're welcome to spell them as camelCase in your source code if you
feel like it, but don't expect that
Nico Sabbi wrote:
>
> Tom Lane ha scritto:
> > Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> >
> >> After discovering that pg_get_serial_sequence behaves in a bit
> >> strange way[1] when it deals to case sensitiveness
> >>
> >
> > The SQL standard specifies that unquoted identifier
1 - 100 of 272 matches
Mail list logo
