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 (generate_series(
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:
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
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
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 exact
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, (sele
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
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
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 S
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 t
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 , it's a
.
---
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, 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 use
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
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
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 lo
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 A
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
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 (not-a
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 capabili
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'
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
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
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 isAutovacuu
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 pro
>
> 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
---
"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
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
Updat
> 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 = 'language_count
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
>
> 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
32 matches
Mail list logo
