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
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
On Thu, Dec 12, 2013 at 12:47 PM, Dev Kumkar devdas.kum...@gmail.comwrote:
+ hackers
On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar devdas.kum...@gmail.comwrote:
On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar devdas.kum...@gmail.comwrote:
Actually for searches lower will work.
But the other
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
Can case-insensitive collation help here?
On Wed, Dec 11, 2013 at 4:55 PM, Dev Kumkar devdas.kum...@gmail.com 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.
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()
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
On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar devdas.kum...@gmail.com 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
+ hackers
On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar devdas.kum...@gmail.comwrote:
On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar devdas.kum...@gmail.comwrote:
Actually for searches lower will work.
But the other important aspect is 'inserts' which would result 2 rows if
the values are 'A'
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
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
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.
According to the
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 row)
template1=#
On Mon, Jun 17, 2013 at 11:11 PM, Stefan Drees ste...@drees.name 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
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 evaluated at
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
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
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
Gauthier, Dave dave.gauth...@intel.com 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
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 way
2013/2/16 Glenn Pierce glennpie...@gmail.com:
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
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
On 2012-09-01, Chris Angelico ros...@gmail.com wrote:
On Sat, Sep 1, 2012 at 12:07 PM, David Johnston pol...@yahoo.com 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 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
On Sat, Sep 1, 2012 at 6:19 AM, David Johnston pol...@yahoo.com wrote:
On Aug 31, 2012, at 22:49, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
On Aug 31, 2012, at 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
That said you
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 Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos tkalf...@gmail.com 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.
David Johnston pol...@yahoo.com writes:
On Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos tkalf...@gmail.com 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
On Aug 31, 2012, at 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
On Aug 31, 2012, at 19:14, Thalis Kalfigkopoulos tkalf...@gmail.com wrote:
This didn't work as expected (the NULL's persisted):
...CASE sum(foo) WHEN NULL THEN 0 ELSE sum(foo) END...
On Sat, Sep 1, 2012 at 12:07 PM, David Johnston pol...@yahoo.com 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
David Johnston pol...@yahoo.com writes:
On Aug 31, 2012, at 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com 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
On Aug 31, 2012, at 22:49, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
On Aug 31, 2012, at 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com writes:
That said you might want to try
SUM(COALESCE(foo, 0))
Actually I'd go with
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
On Mon, Jun 6, 2011 at 2:24 PM, Heine Ferreira heine.ferre...@gmail.com 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
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
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
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
--
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
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
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 phil...@softworks.com:
Hi,
I'm moving over from MS SQL. I've been googling this for ages now and
suprisingly cannot find a clear answer.
I
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
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
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?
2011/1/13 Phillip Smith phil...@softworks.com:
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
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
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 like
Hello
try to explicit cast
select 't'::boolean;
regards
Pavel Stehule
2009/10/14 Gus Waddell angus.wadd...@palcare.com.au:
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
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:
$
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-general
...@cisco.com
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 postgres to change the user name, I get
this problem:
postgres
-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 Mickey;
ERROR: role mickey already exists
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,
On 24/03/2009 20:25, Berdam wrote:
aer
?
--
Raymond O'Donnell, Director of Music, Galway
*De:* John R Pierce pie...@hogranch.com
*Para:* Will Rutherdale (rutherw) ruth...@cisco.com
*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
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
Kevin Murphy mur...@genome.chop.edu 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
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:
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
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
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 after
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 to
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
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
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 the
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
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 discussion
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
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 return
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 do versus what
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 this column name
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%' then '' end
BTW, should you have an else clause in there? - What happens when the
comparison fails?
As Tom said, a null value would be returned.
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
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
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
Is there any control structure statement similar to select case ... ? If yes
how to use it. I have tried to use, case when expression then expression
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.
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
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 expression then expression
end, but not worked well as I want to use other control structures and sql
statements to be executed for
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 structure
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
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 identifiers are case-insensitive.
You're welcome to spell
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 identifiers are
On Fri, 18 Jan 2008 13:14:33 +0100
Nico Sabbi [EMAIL PROTECTED] wrote:
yet I find disturbing that Postgres doesn't make the effort
to respect the case specified by the user. If I created a field
called REF why should Postgres call it ref in the output of
queries if the standard doesn't
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
1 - 100 of 267 matches
Mail list logo
