Apologies if this posts twice... I've run into issues with the
listserv lately.
I am implementing an autosuggest-style text input for my site, where a
user can start typing the name of a thing (call it a 'Foo'), and get a
list of all things whose name starts with the string the user typed.
On Wednesday 06 August 2008 07:59, Rafael Domiciano wrote:
> I have read the article... tnks, very helpful.
>
> But, can I create a index using function like "substring"? I would like to
> create something like this:
Actually, Richard Broersma is the one who commented on that approach. I have
nev
I have read the article... tnks, very helpful.
But, can I create a index using function like "substring"? I would like to
create something like this:
CREATE INDEX indtest_01 ON table_01
((SUBSTRING(month_year, 3, 4) || SUBSTRING(month_year, 1, 2))
2008/8/4 Terry Lee Tucker <[EMAIL PROTECTED]>
>
On Monday 04 August 2008 11:09, Frank Bax wrote:
> Terry Lee Tucker wrote:
> > On Monday 04 August 2008 10:05, Richard Broersma wrote:
> >> On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
> >>> In some db's if you
> >>> use a lower() or upr() it will always do a table scan ins
Terry Lee Tucker wrote:
On Monday 04 August 2008 10:05, Richard Broersma wrote:
On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
In some db's if you
use a lower() or upr() it will always do a table scan instead of using a
index
True, this would also happen in PostgreSQL.
On Monday 04 August 2008 10:05, Richard Broersma wrote:
> On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
> >In some db's if you
> > use a lower() or upr() it will always do a table scan instead of using a
> > index
>
> True, this would also happen in PostgreSQL. However, you
On Mon, Aug 4, 2008 at 6:54 AM, Mike Gould <[EMAIL PROTECTED]> wrote:
>In some db's if you
> use a lower() or upr() it will always do a table scan instead of using a
> index
True, this would also happen in PostgreSQL. However, you can overcome
this by creating a "functional" index:
http://www.po
In the application that we are working on, all data searches must be case
insensitive.
Select * from test where column1 = 'a' and Select * from test where column1 =
'A' should always be the same and use the index if column1 is indexed. In
order to do this am I going to be required to us
Hi Scott ,
No. I provide one small fake example.
I want to know how to use case when in update/set clause as the following:
update test
set id = case when id = 5 then 6 else id end;
Well, I think my point stands, that this stuff really belongs in a
where clause. The way you're doing it
On Wed, Mar 12, 2008 at 9:11 AM, Emi Lu <[EMAIL PROTECTED]> wrote:
> >>
> >> I use one small Example, table: test
> >> =
> >> id
> >> ==
> >> 5
> >> 6
> >> 8
> >>
> >> try to update test.id
> >>
> >>
> >> update test
> >>
> >> case
> >> when id
I use one small Example, table: test
=
id
==
5
6
8
try to update test.id
update test
case
when id =5 then SET id = 6
end
;
would this work:
update test set id=5 where id=6;
No. I provide one small fake example.
I want to know how to use case w
On Wed, Mar 12, 2008 at 8:47 AM, Emi Lu <[EMAIL PROTECTED]> wrote:
> Hello,
>
> May I know can "case when " used by update clause. If yes, how?
>
> I use one small Example, table: test
> =
> id
> ==
> 5
> 6
> 8
>
> try to update test.id
>
>
> update test
>
> c
Aaron Bono wrote:
On Wed, Mar 12, 2008 at 10:47 AM, Emi Lu <[EMAIL PROTECTED]> wrote:
Hello,
May I know can "case when " used by update clause. If yes, how?
I use one small Example, table: test
=
id
==
5
6
8
try to update test.id
update test
case
when id =5 th
Hello,
May I know can "case when " used by update clause. If yes, how?
I use one small Example, table: test
=
id
==
5
6
8
try to update test.id
update test
case
when id =5 then SET id = 6
end
;
Thanks!
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.or
Ertel, Steve wrote:
I see that I can create a table with a mixed case name as long as the
name is wrapped in quotes. Is there a setting to allow upper case
and mixed case names for database tables, fields, etc, without having
to wrap each in quotes?
No, SQL defines identifiers as case-insensit
On Tue, Dec 11, 2007 at 11:05:25AM -0600, Ertel, Steve wrote:
> is wrapped in quotes. Is there a setting to allow upper case and mixed
> case names for database tables, fields, etc, without having to wrap each
> in quotes?
No, sorry. The always-one-case rule for unquoted identifiers is ANSI
con
am Tue, dem 11.12.2007, um 11:05:25 -0600 mailte Ertel, Steve folgendes:
> 
> I see that I can create a table with a mixed case name as long as the name is
> wrapped in quotes. Is there a setting to allow upper case and mixed case
> names
> for database tables, fields, etc, without having to
I see that I can create a table with a mixed case name as long as the name is
wrapped in quotes. Is there a setting to allow upper case and mixed case names
for database tables, fields, etc, without having to wrap each in quotes?
Thanks,
SteveE
Now it is working. Thank you for your interest.
Ezequias
2007/2/28, Andrew Sullivan <[EMAIL PROTECTED]>:
On Wed, Feb 28, 2007 at 10:02:38AM -0300, Ezequias Rodrigues da Rocha wrote:
> Hi list,
>
> it is possible to use case with character (1) ?
>
> I am having problems to formate the SQL stateme
Am Mittwoch, 28. Februar 2007 14:02 schrieb Ezequias Rodrigues da Rocha:
> it is possible to use case with character (1) ?
Have you tried it?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help
On Wed, Feb 28, 2007 at 10:02:38AM -0300, Ezequias Rodrigues da Rocha wrote:
> Hi list,
>
> it is possible to use case with character (1) ?
>
> I am having problems to formate the SQL statement.
Your example looked like it worked.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Users never remark,
Hi list,
it is possible to use case with character (1) ?
I am having problems to formate the SQL statement.
I have:
SELECT * FROM test;
a
---
A
B
C
SELECT a,
CASE WHEN a='A' THEN 'one'
WHEN a='B' THEN 'two'
ELSE 'other'
END
FROM test;
a | case
---+-
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
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 ide
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*
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");
$s
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
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-insen
Martijn van Oosterhout wrote:
On Sat, Dec 02, 2006 at 11:08:51AM -0700, Ken Johanson wrote:
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 instead of lower casing them a
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 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 camel
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
CREA
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);
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*
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 globall
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
myCol
beau hargis wrote:
> Having installed DB2 Enterprise today and taking it for a spin, it does
> indeed
> behave in a similar manner. However, after reading through both
> specifications, it seems that DB2 follows more of the spec than PostgreSQL.
> The specifications state that for purpose of co
-Original Message-
From: Stephan Szabo [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 10:23 AM
To: Chuck McDevitt
Cc: Tom Lane; beau hargis; pgsql-sql@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
On Tue, 31 Oct
On Tue, Oct 31, 2006 at 12:55:46PM -0500, Andrew Dunstan wrote:
> To this you propose, as I understand it, to have a fourth possibility
> which would be spec compliant for comparison purposes but would label
> result set columns with the case preserved name originally used (or
> would you use th
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:
> CREA
title like "sum(WeeklySales)"
-Original Message-
From: Tom Lane [mailto:[EMAIL 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 Preservati
]
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 certa
r 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 the
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
IL PROTECTED] On Behalf Of Tom Lane
Sent: 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 th
"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 desig
"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
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 col
"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 and a are
equivalent if the of
beau hargis <[EMAIL PROTECTED]> writes:
> Considering the differences that already exist between database systems and
> their varying compliance with SQL and the various extensions that have been
> created, I do not consider that the preservation of case for identifiers
> would violate any SQL s
On Friday 27 October 2006 19:38, Joe wrote:
> Hi Beau,
>
> On Fri, 2006-10-27 at 16:23 -0700, beau hargis wrote:
> > I am hoping that there is an easy way to obtain case-preservation with
> > case-insensitivity, or at the very least, case-preservation and complete
> > case-sensitivity, or case-pres
> Again, I am looking for a way (magic, patches, whiskey, etc) that will give
> me
> case-preservation with EITHER case-sensitivity OR case-insensitivity, but not
> both as I am seeing.
>
> Thanks in advance. I am hoping to find a solution to this so I can actually
> convert one of our databas
> Case was preserved. Now lets add the foreign key just as we did before (note
> that the case in the table definition and the ALTER TABLE query is the same):
>
> ALTER TABLE user_profile ADD CONSTRAINT fk_uproftype FOREIGN KEY
> (userProfileTypeId) REFERENCES user_profile_type (userProfileType
Hi Beau,
On Fri, 2006-10-27 at 16:23 -0700, beau hargis wrote:
> I am hoping that there is an easy way to obtain case-preservation with
> case-insensitivity, or at the very least, case-preservation and complete
> case-sensitivity, or case-preservation and a consistant case-conversion
> strategy
At 07:23 PM 10/27/06, beau hargis wrote:
I am aware of the double-quote 'feature' which indicates that an element
should be treated in a case-sensitive way. This as been the 'answer' to every
question of this sort. This 'feature' does not solve the problem and
introduces other problems.
If you
Hello all.
As this is my first post to this particular mailing list, let me preface this
with a couple of items:
1) I have, indeed, searched far and wide for the answer to my question. I have
read and understood the responses to similar posts posing similar questions.
My next stop after this i
My environment setup as:
show lc_ctype;
lc_ctype
-
fr_CA.UTF-8
(1 row)
fis=> SELECT 'Ä' ~* 'ä';
?column?
--
f
(1 row)
fis=> SELECT 'Ä' ilike 'ä';
?column?
--
f
(1 row)
I got the same result: false
"=?ISO-8859-1?Q?Ragnar_=D6sterlund?=" <[EMAIL PROTECT
"=?ISO-8859-1?Q?Ragnar_=D6sterlund?=" <[EMAIL PROTECTED]> writes:
> I'm not sure if this is a bug or if I'm doing something wrong. I have
> a database encoded with ISO-8859-1, aka LATIN1. When I do something
> like:
> SELECT 'Ä' ~* 'ä';
> it returns false.
Check the database's locale setting (LC
Hi,
I'm not sure if this is a bug or if I'm doing something wrong. I have
a database encoded with ISO-8859-1, aka LATIN1. When I do something
like:
SELECT 'Ä' ~* 'ä';
it returns false. If i do:
SELECT 'A' ~* 'a';
I get true. According to specification, both should return true.
Anyone knows wh
On Wed, 28 Jun 2006 10:48:31 -0700, Bricklen Anderson wrote
> Keith Worthington wrote:
> >>> "Keith Worthington" <[EMAIL PROTECTED]> writes:
> >>> The following is a section of code inside an SQL function.
> >> On Wed, 28 Jun 2006 12:16:29 -0400, Tom Lane wrote
> >> SQL, or plpgsql? It looks to me
Keith Worthington wrote:
Hi All,
The following is a section of code inside an SQL function. When I attempt to
run it I get the error message '"CASE" is not a variable'. If I split this into
two queries (one for each variable) it works fine. Obviously I have a work
around but I would like to
Keith Worthington wrote:
"Keith Worthington" <[EMAIL PROTECTED]> writes:
The following is a section of code inside an SQL function.
On Wed, 28 Jun 2006 12:16:29 -0400, Tom Lane wrote
SQL, or plpgsql? It looks to me like misuse of the plpgsql INTO clause
(there can be only one).
> > "Keith Worthington" <[EMAIL PROTECTED]> writes:
> > The following is a section of code inside an SQL function.
>
> On Wed, 28 Jun 2006 12:16:29 -0400, Tom Lane wrote
> SQL, or plpgsql? It looks to me like misuse of the plpgsql INTO clause
> (there can be only one).
>
>
"Keith Worthington" <[EMAIL PROTECTED]> writes:
> The following is a section of code inside an SQL function.
SQL, or plpgsql? It looks to me like misuse of the plpgsql INTO clause
(there can be only one).
regards, tom lane
---(end of broadcast)---
Hi All,
The following is a section of code inside an SQL function. When I attempt to
run it I get the error message '"CASE" is not a variable'. If I split this into
two queries (one for each variable) it works fine. Obviously I have a work
around but I would like to understand what I am doing
Dear Lane, is that what you want?
CREATE TABLE network_nodes (
node_id SERIAL PRIMARY KEY,
node_name VARCHAR,
default_gateway_interface_id INTEGER
);
CREATE TABLE router_interfaces (
interface_id SERIAL PRIMARY KEY,
node_id INT REFERENCES network_nodes
);
CREATE VIEW current
lto:[EMAIL PROTECTED]
Sent: Saturday, August 20, 2005 7:25 AM
To: pgsql-sql@postgresql.org
Cc: [EMAIL PROTECTED]
Subject: RE: SQL CASE Statements
> Has anybody done this? If so, can you send me a sample?
CREATE TEMPORARY TABLE fruits (id SERIAL, name TEXT);
INSERT INTO fruits VALUES (DEFAULT,
> Has anybody done this? If so, can you send me a sample?
CREATE TEMPORARY TABLE fruits (id SERIAL, name TEXT);
INSERT INTO fruits VALUES (DEFAULT, 'banana');
INSERT INTO fruits VALUES (DEFAULT, 'apple');
CREATE TEMPORARY TABLE food (id SERIAL, name TEXT);
INSERT INTO food VALUES (DEFAULT, 'apple'
ar" is the
table you check for existence.
Dmitri
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lane Van Ingen
> Sent: Thursday, August 18, 2005 9:32 PM
> To: pgsql-sql@postgresql.org
> Subject: [SQL] SQL CASE Statements
&
In the following CASE statement, is it possible to put a SELECT ... WHERE
EXISTS
in the of a CASE statement, and have it work?
The I want to do is to yield a result of '1' if the statement
finds
the value 'a' in a table (EXISTS evaluates true), and '0' if it evaluates
false
('a' not found).
SEL
Markus Bertheau =?UTF-8?Q?=E2=98=AD?= <[EMAIL PROTECTED]> writes:
> is it planned to support the following insert syntax?
> INSERT INTO table VALUES (CASE WHEN arg_whatever IS NULL THEN DEFAULT
> ELSE arg_whatever END);
No. AFAICS, SQL99 only defines DEFAULT as the direct INSERT or UPDATE
target
Hi,
is it planned to support the following insert syntax?
INSERT INTO table VALUES (CASE WHEN arg_whatever IS NULL THEN DEFAULT
ELSE arg_whatever END);
I have the DEFAULT inside the CASE expression in mind.
Markus
--
Markus Bertheau ☭ <[EMAIL PROTECTED]>
---(end of br
El Lun 21 Mar 2005 11:29, Alvaro Herrera escribió:
> On Mon, Mar 21, 2005 at 11:18:38AM -0300, Martín Marqués wrote:
>
> Hey Martin,
>
> > I have this query which has a CASE in the middle to give me special
results.
> > The problem is that it doesn't interpret my columns as it should.
> >
> >
On Mon, Mar 21, 2005 at 11:18:38AM -0300, Martín Marqués wrote:
Hey Martin,
> I have this query which has a CASE in the middle to give me special results.
> The problem is that it doesn't interpret my columns as it should.
>
> Here is the porblem:
>
> siprebi=> SELECT getvencimientosancion(190
I have this query which has a CASE in the middle to give me special results.
The problem is that it doesn't interpret my columns as it should.
Here is the porblem:
siprebi=> SELECT getvencimientosancion(190) AS vence, (SELECT codigo FROM
sanciones WHERE persona = (SELECT persona FROM usuarios
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> Mac os x, postgresql 8.0.1
> initdb --locale=es_ES ~/testdb
> ...
> The database cluster will be initialized with locale es_ES.
> initdb: could not find suitable encoding for locale "es_ES"
> Rerun initdb with the -E option.
I looked into this and fi
I seem to have a problem with controlling the locale.
Mac os x, postgresql 8.0.1
./configure --with-rendezvous --enable-thread-safety
--enable-locale
but when I try:
initdb --locale=es_ES ~/testdb
I get:
The files belonging to this database system will be
owned by user "postgres".
This user
Peter Eisentraut wrote:
>
> Christoph Haller wrote:
> > It seems to me under hpux the sort is done case sensitive,
> > as would one expect on SQL_ASCII encoding, whereas
> > under linux a case insensitive sort is done.
>
> The sort order depends entirely on the locale that you specify to initdb
>
Christoph Haller wrote:
> It seems to me under hpux the sort is done case sensitive,
> as would one expect on SQL_ASCII encoding, whereas
> under linux a case insensitive sort is done.
The sort order depends entirely on the locale that you specify to initdb
(not the encoding). Please check the d
I am seeing different ORDER BY results
on a character column on different machines.
I have (1)
ResyDBE=# select version();
version
PostgreSQL 7.4.5 on hppa-hp-hpux10.20, compiled by GCC gcc (
Dear Jaime ,
CREATE OR REPLACE FUNCTION
"public"."rec_f_consultarplanificacionrubros" (smallint, smallint,
char(9), smallint, smallint, smallint, char(2)) RETURNS SETOF
"public"."rec_td_rubrosplanificados" AS '
select rub_codigo, cpa_valor, cpa_fechavencimiento
from rec_m_cuadropagosc
--- Jaime Casanova <__> wrote:
> hi all,
>
> Well i rethink my design 'cause the other was too slow. but all
> solutions
> involves new problems... now my problem is with a function of this
> type:
>
>
> CREATE OR REPLACE FUNCTION
> "public"."rec_f_consultarplanificacionrubros"
> (smallint, sm
hi all,
Well i rethink my design 'cause the other was too slow. but all solutions
involves new problems... now my problem is with a function of this type:
CREATE OR REPLACE FUNCTION "public"."rec_f_consultarplanificacionrubros"
(smallint, smallint, char(9), smallint, smallint, smallint, char(2))
On Thu, Sep 25, 2003 at 08:46:39PM -0700, Josh Berkus wrote:
>
> NULLIF is the converse of COALESCE().
Oh, ooops! My apologies.
> Any idea when you're going to overhaul the CookBook?
*sighs*
The software is pretty much ready. I'll have time to install and configure
it next week, after my e
Roberto,
> > Another problem is in creating function...
> > How can i create a function that accept and return any type. the type
> > "any" is not allowing as parameter or return type. Is it possible? i want
> > to create a function similar to NULLIF().
>
> Use the standard coalesce().
NULLIF is
Thanks to all of you for your valuable suggesstions
does postgresql internally uses the = operator(text,text) for any other purposes.
i think that overloading it solves the index problem too...
Tom Lane <[EMAIL PROTECTED]> wrote:
Josh Berkus <[EMAIL PROTECTED]>writes:>> How can i create a f
On Wed, Sep 24, 2003 at 23:30:08 -0600,
Roberto Mello <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2003 at 08:35:50PM -0700, George A.J wrote:
>
> > Another problem is in creating function...
> > How can i create a function that accept and return any type. the type "any" is not
> > allowing as
Josh Berkus <[EMAIL PROTECTED]> writes:
>> How can i create a function that accept and return any type. the type "any"
>> is not allowing as parameter or return type. Is it possible? i want to
>> create a function similar to NULLIF().
> You can't, nor will you be able to -- in te future, some 7.4
On Wed, Sep 24, 2003 at 08:35:50PM -0700, George A.J wrote:
> hai
>
> i am using postgresql 7.3.x. I am converting a database in MS SQL server to
> PostgreSQL.
>
> The main problems i am facing is that in sql server the text comparisons are case
> insensitive. how can i compare text case ins
On Wed, 24 Sep 2003, George A.J wrote:
> The main problems i am facing is that in sql server the text comparisons
> are case insensitive. how can i compare text case insensitive in
> postgresql without using an upper() or lower() function in both sides
> (=). Is there any option to set in postgre
jinujose,
> i am using postgresql 7.3.x. I am converting a database in MS SQL server to
> PostgreSQL.
Good luck to you!
> The main problems i am facing is that in sql server the text comparisons
> are case insensitive. how can i compare text case insensitive in postgresql
> without using an uppe
hai
i am using postgresql 7.3.x. I am converting a database in MS SQL server to PostgreSQL.
The main problems i am facing is that in sql server the text comparisons are case insensitive. how can i compare text case insensitive in postgresql without using an upper() or lower() function in both
On Friday 30 May 2003 7:01 pm, C F wrote:
> I was afraid someone was going to ask that :)
> Okay, I'll do my best at explaining where I'm coming from
[snip long but detailed description I asked for -thanks]
Right - I've done something similar to this before, and I ended up building my
SQL on
I was afraid someone was going to ask that :)
Okay, I'll do my best at explaining where I'm coming from
I'm working on a mapping application it is user-configurable. What this means (as it pertains to this disucssion) is that the through a configuration file, the user is able to define the ru
Richard Huxton <[EMAIL PROTECTED]> writes:
> On Friday 30 May 2003 4:47 pm, C F wrote:
>> select
>> (case when column1 = column2 then column3 end) as alias1,
>> (case when column1 = column2 then column4 end) as alias2,
>> (case when column1 = column2 then column5 end) as alias3,
>> (case when colum
On Friday 30 May 2003 4:47 pm, C F wrote:
> Hello,
> I already tried this same basic question with no response maybe I was
> too wordy.
I think it's more a case of nobody seeing a better way.
> select
> (case when column1 = column2 then column3 end) as alias1,
> (case when column1 = colu
On Friday 06 Dec 2002 12:33 pm, Pedro Igor wrote:
> Someone knows how config the postgresql for case-insensitive mode ?
There isn't really a case-insensitive mode (for various reasons to do with
locales AFAICT).
There are various case-insensitive comparisons: ILIKE instead of LIKE etc.
A very c
Someone knows how config the postgresql for
case-insensitive mode ?
Pedro Igor
Jordan Reiter wrote:
> Are string comparisons in postgresql case sensitive?
>
> I keep on having this response:
>
> SELECT *
> FROM People
> WHERE first_name='jordan'
>
> Result: 0 records
>
> SELECT *
> FROM People
> WHERE first_name='Jordan'
>
> Result: 1 record
It's case-sensitive. You ca
Ian Barwick wrote:
>
> Anyone know what the ANSI standard is? I don`t recall any other
> database apart from MySQL which default to case-insensitive
> CHAR or VARCHAR columns.
SQL:1999 says collation dependent.
Jochem
---(end of broadcast)---
TI
1 - 100 of 156 matches
Mail list logo
