"William ZHANG" <[EMAIL PROTECTED]> wrote
> lc_messages = 'Chinese_People''s Republic of China.936' # locale
> for
> system error message
>
Diff current version vs. some earlier version, you see this:
/*
* signal handler in case we are interrupted.
@@ -1951,12 +2035,12 @@ escape_quo
On K, 2005-09-21 at 09:01 +0400, Oleg Bartunov wrote:
> On Tue, 20 Sep 2005, Martijn van Oosterhout wrote:
> > What syntax were you envisioning? Does this value just need to be
> > passed to GiST at the creation of the the index, or does it actually
> > need to remembered by the backend and passed
pg_dump emits COMMENT ON DATABASE (if the database has a comment)
even when dumping only an individual schema or table. That seems
inappropriate, especially when copying data to a different cluster
where the named database might not exist or might have a different
comment that shouldn't be overwri
On Tue, 20 Sep 2005, Martijn van Oosterhout wrote:
On Tue, Sep 20, 2005 at 11:26:26PM +0400, Oleg Bartunov wrote:
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
As has been pointed ou
Bruce Momjian wrote:
Andrew Dunstan wrote:
While preparing for a presentation, I noticed some mildly ugly effects
with log_line_prefix during session startup if log_connections is turned on.
Example (log_line_prefix = '%t [EMAIL PROTECTED] %r %p %c:%l'):
2005-09-19 19:16:39 EDT [EMAIL P
On Tue, Sep 20, 2005 at 06:45:07PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > > What do these URL's have that the current TODO does not?
> > >
> > > * Consider using hash buckets to do DISTINCT, rather than sorting
> > >
> > > This would be beneficial when there are few distinct valu
Jim C. Nasby wrote:
> > What do these URL's have that the current TODO does not?
> >
> > * Consider using hash buckets to do DISTINCT, rather than sorting
> >
> > This would be beneficial when there are few distinct values. This is
> > already used by GROUP BY.
>
> Maybe it's just me, but t
On Tue, Sep 20, 2005 at 05:05:05PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
> > >
> > > Added to TODO:
> > >
> > > * Allow DISTINCT to use hashing like GROUP BY
> >
> > 3 lines above we have...
> > Consider using hash
Martijn van Oosterhout writes:
> What syntax were you envisioning? Does this value just need to be
> passed to GiST at the creation of the the index, or does it actually
> need to remembered by the backend and passed each call?
I should think that the index ought to remember any such info for its
Jim C. Nasby wrote:
> On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
> >
> > Added to TODO:
> >
> > * Allow DISTINCT to use hashing like GROUP BY
>
> 3 lines above we have...
> Consider using hash buckets to do DISTINCT, rather than sorting
> This would be beneficial when th
On 8/18/2005 5:14 AM, Qingqing Zhou wrote:
""Marc G. Fournier"" <[EMAIL PROTECTED]> writes
I've done a grep through the code, to see if its something that we do use,
and
it doesn't seem to come back with anything ... I believe its considered
common knowledge that 'swapping' for a database is
On Tue, Sep 20, 2005 at 11:26:26PM +0400, Oleg Bartunov wrote:
> it's desirable to be able to pass parameters to CREATE INDEX for
> GiST indices. Does SQL standard has something about that so we could
> implement it for 8.2 ?
As has been pointed out, INDEXes arn't in the SQL spec at all, so you
ca
Oleg Bartunov wrote:
Hi there,
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
According to the docs:
"CREATE INDEX is a PostgreSQL language extension. There are no
provisions for
On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
>
> Added to TODO:
>
> * Allow DISTINCT to use hashing like GROUP BY
3 lines above we have...
Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few distinct values.
Can y
Hi there,
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
Example from real life project - performance of tsearch2 could be
greatly improved if decrease signature size in gistidx.h, which
On Mon, Sep 19, 2005 at 11:09:50PM -0600, Michael Fuhr wrote:
> In an earlier message you said that "the owner of the machine has
> been completely unhelpful about providing any information to track
> it down." Is he not responding at all, or is he responding but
> with not enough information?
Ye
On Thu, Sep 15, 2005 at 11:24:23PM -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Thursday 15 September 2005 15:41, Alvaro Herrera wrote:
> >> Robert Treat reminded me the other day that we don't currently save
> >> pg_autovacuum settings on pg_dump.
>
> > ISTM this is a
On Tue, Sep 20, 2005 at 01:17:10PM -0400, Bruce Momjian wrote:
> I worked with Jim Nasby and we found this is the line that is failing on
> Gerbil in the build farm during initdb: tqual.c, line 844 in 8.0.X
>
> if (HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid)
>
> This particular line
I worked with Jim Nasby and we found this is the line that is failing on
Gerbil in the build farm during initdb: tqual.c, line 844 in 8.0.X
if (HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid)
This particular line was last modified in 2002. However, this was a
file that was changed as
Le Lundi 19 Septembre 2005 07:38, Peter Eisentraut a écrit :
> I think beta 2 is a good time to start fixing up the translations again.
Great :)
I think I'm gonna work on it soon because I'm nearly done with the translation
of the 8.1-beta2 manual.
> As I had previously announced, long-time tra
The fact that cmpb isn't helping proves that getting the cache line
in a
read-only fashion does *not* do enough to protect the xchgb in this
way.
But maybe another locking instruction would. Comments?
regards, tom lane
Hi, Tom!
Possible you help next link
'Replay: Unkn
Cool. We look forward to it.On 9/19/05, Mark Dilger <[EMAIL PROTECTED]> wrote:
Jonah H. Harris wrote:> Mark,>> If you don't mind contributing the changes, we'd be glad to take a look> at them. Thanks.>> -Jonah>Ok, we will post it back soon. We have tested it on two different 64-bit
architectures
Bruce Momjian wrote:
Andrew Dunstan wrote:
I'm also unclear why we get two lines at the start of each connection -
that seems like a bug, or is it due to some sort of protocol
negotiation. This is a fresh FC4 machine with only pg 8.0.3 ever installed.
I can not reproduce your pro
I'm going to take from this discussion that there is no use for the
USING clause with operators not in an operator class and that if this
changes we won't be seriously inconveniencing anybody.
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Patent. n. Genius is 5% i
pgsql-8.1beta2 "make check" failed on Win32 under MinGW.
Here is some lines from log/initdb.log.
creating configuration files ... ok
creating template1 database in
C:/MSYS/home/wlzhang/postgresql-8.1beta2/src/test/regress/tmp_check/data/bas
e/1 ... FATAL: syntax error in file
"C:/MSYS/home/wlzha
25 matches
Mail list logo