Tatsuo Ishii [EMAIL PROTECTED] wrote:
For me the idea that a text-search configuration maps to a
locale/language seems to be totally wrong. IMO an encoding/charset
could include several languages and a text-search configuration should
be mapped to an encoding/charset, rather than a language.
Tatsuo Ishii [EMAIL PROTECTED] wrote:
For me the idea that a text-search configuration maps to a
locale/language seems to be totally wrong. IMO an encoding/charset
could include several languages and a text-search configuration should
be mapped to an encoding/charset, rather than a
Tatsuo Ishii [EMAIL PROTECTED] wrote:
You know that PostgreSQL allows only one locale for a PostgreSQL
cluster, and the fact that text-search being depending on locale
prevent it from processing multi language text.
The only solution I can think of today is creating new parser which
can
The correct solution is probably we will have multiple locales in
single database cluster. We should set the locale after deciding
the encoding nowm, but I think the current implementation is wrong
because locale depends on encoding, but the opposite is not true.
(locale =
My suggested edit of the Overview section of the Release Notes. The
emphasis is on user-noticeable features, so some of the major internal
changes are lower down the list. Some items have been removed or placed
below the performance features.
New data types for SQL/XML, enum and uuid types
Simon Riggs [EMAIL PROTECTED] writes:
Asynchronous Commit allows some transactions to commit faster than
others, offering a trade-off between performance and durability for
specific transaction types only
A lot of users will be confused about what asynchronous commit does. I think
it's
I'm not sure the locale per database solution is a silver bullet.
With this, still we cannot solve the issue, for example, a LATIN1
encoded text includes several languages at a time, thus it needs
multiple locales. Or we cannot have multiple different language
columns, tables at a time
Something to add to the TODO:
EXPLAIN doesn't show Datum sorts explicitly that occur because of
DISTINCT aggregates in the SELECT clause.
EXPLAIN looks like this
postgres=# explain select count(distinct col3) from blah3;
QUERY PLAN
I have a few questions from recent attempts to perform a join between
two tables, where one table has an integer array in it. Join is of the
form:
select ... from t1 where col1 = any (select col2 from t2);
Not sure whether these are bugs, intentional, incomplete functionality.
I've solved the
On Thu, 2007-10-04 at 17:33 -0400, Alvaro Herrera wrote:
Simon Riggs escribió:
Seems like we don't need to mess with the deadlock checker itself.
We can rely on the process at the head of the lock wait queue to sort
this out for us. So all we need do is look at the isAutovacuum flag on
Simon Riggs [EMAIL PROTECTED] writes:
...which is fine on just one table, but I want to join...
postgres=# select * from c where col1 = any (select col2 from c);
ERROR: operator does not exist: integer = integer[]
That isn't a join. Are you looking for something like
select * from c, c as
Tatsuo Ishii [EMAIL PROTECTED] writes:
You know that PostgreSQL allows only one locale for a PostgreSQL
cluster, and the fact that text-search being depending on locale
prevent it from processing multi language text.
I think you are confusing the capabilities of tsearch with the fact
that we
On Fri, 2007-10-05 at 10:52 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
...which is fine on just one table, but I want to join...
postgres=# select * from c where col1 = any (select col2 from c);
ERROR: operator does not exist: integer = integer[]
That isn't a join.
Simon Riggs [EMAIL PROTECTED] writes:
1. Why doesn't the subselect work?
Because x = ANY (SELECT y FROM ...) is defined by the SQL standard to
involve performing x = y at each row of the SELECT output. There's
no wiggle room there.
The standard does not specify any meaning for x = ANY
On Fri, 5 Oct 2007, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
You know that PostgreSQL allows only one locale for a PostgreSQL
cluster, and the fact that text-search being depending on locale
prevent it from processing multi language text.
I think you are confusing the
On Fri, 2007-10-05 at 16:04 +0100, Simon Riggs wrote:
select * from c, c as c2 where c.col1 = any (c2.col2)
That works, thanks.
As I said, I already solved the problem a different way. I was looking
to understand the 3 questions I raised along the way.
Can you throw any light on those
Jeff Davis [EMAIL PROTECTED] writes:
You could do something like:
SELECT * FROM c AS c1, c AS c2 WHERE ARRAY[c1.col1] @ ANY(SELECT c2.col2);
Good point --- actually he could convert it back to the original
subselect style, as long as he's using the correct operator:
SELECT * FROM c WHERE
On Fri, 2007-10-05 at 12:29 -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
You could do something like:
SELECT * FROM c AS c1, c AS c2 WHERE ARRAY[c1.col1] @ ANY(SELECT c2.col2);
Good point --- actually he could convert it back to the original
subselect style, as long as he's
On Fri, 2007-10-05 at 09:46 -0700, Jeff Davis wrote:
On Fri, 2007-10-05 at 12:29 -0400, Tom Lane wrote:
The one-element-array trick seems a bit awkward though. I wonder
why we don't have an anyelement @ anyarray kind of operator...
I thought we did -- until I decided to test my example
On Fri, 2007-10-05 at 11:42 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. Why doesn't the subselect work?
Because x = ANY (SELECT y FROM ...) is defined by the SQL standard to
involve performing x = y at each row of the SELECT output. There's
no wiggle room there.
The
On Fri, 2007-10-05 at 11:24 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Asynchronous Commit allows some transactions to commit faster than
others, offering a trade-off between performance and durability for
specific transaction types only
A lot of users will be
Simon Riggs [EMAIL PROTECTED] writes:
I'll look at documenting that.
I think the problem here is you've not bothered to read the manual,
because all of these behaviors *are* documented; two of them are
furthermore required by the SQL standard.
regards, tom lane
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
The inner select returns a ROW, yet we treat it as a single column
value.
The inner select does not return a row. It's not a row subquery, it's a
scalar subquery.
On Thu, Oct 04, 2007 at 02:12:14PM -0400, Tom Lane wrote:
I see that libpq manufactures three different .def files, whereas the
ecpg code is only making two. Is this OK or an oversight? I'm not
Not knowing what the third one is for I deliberately created only two.
If there is a reason for
On Fri, 2007-10-05 at 13:18 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'll look at documenting that.
I think the problem here is you've not bothered to read the manual,
because all of these behaviors *are* documented; two of them are
furthermore required by the SQL
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
The inner select returns a ROW, yet we treat it as a single column
value.
The inner select does not
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
The inner select returns a ROW, yet we treat it as a single
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
select 1, (select col2 from c), 3;
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
Because we already do exactly that here:
On Fri, 2007-10-05 at 11:24 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:59 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs wrote:
On Fri, 2007-10-05 at 10:32 -0700, Stephan Szabo wrote:
On Fri, 5 Oct 2007, Simon Riggs
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
FWIW I tried this program here, and I get
C ... ANSI_X3.4-1968 - NO MATCH
POSIX ... ANSI_X3.4-1968 - NO MATCH
Note the funny name. Trying initdb with LC_ALL=C correctly uses
SQL_ASCII (I saw
Reading the commit message about the TZ encoding issue I'm curious why this
isn't a more widespread problem. How does gettext now what encoding we want
messages in? How do we prevent things like to_char(now(),'month') from
producing strings in an encoding different from the database's encoding?
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
CREATE TABLE jefftest ( id serial, num int );
INSERT INTO jefftest (num) values (generate_series(1,10));
INSERT INTO jefftest (num) values (generate_series(11,20));
INSERT INTO jefftest (num) values
33 matches
Mail list logo
