Hi,
log_directory is automatically created if not present when starting
the database server. But, stats_temp_directory is not created. Why?
ISTM that current behavior is undesirable.
Is it worth making the patch which creates stats_temp_directory
if not present?
Regards,
--
Fujii Masao
NIPPON
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
A lookahead (the +1) may have pg_standby get stuck as follows.
Am I missing something?
1. the trigger file containing smart is created.
2. pg_standby is executed.
2-1. nextWALfile is restored.
2-2. the trigger file is deleted
Hi,
On Tue, Apr 14, 2009 at 6:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
A lookahead (the +1) may have pg_standby get stuck as follows.
Am I missing something?
1. the trigger file containing smart is created.
2. pg_standby is
On Saturday 11 April 2009 00:54:25 Tom Lane wrote:
It gets worse though: I have seldom seen such a badly designed piece of
syntax as the Unicode string syntax --- see
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL
-SYNTAX-STRINGS-UESCAPE
You scan the string, and
Hi,
On Mon, Apr 13, 2009 at 2:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
But, a lookahead nextWALfile seems to work fine.
if (triggered)
{
if (smartMode nextWALfile exists)
exit(0)
else
{
delete trigger file
exit(1)
}
}
Umm... in this algorithm,
On Saturday 11 April 2009 21:50:29 Josh Berkus wrote:
On 4/11/09 11:47 AM, Marko Kreen wrote:
On 4/11/09, Tom Lanet...@sss.pgh.pa.us wrote:
It gets worse though: I have seldom seen such a badly designed piece
of syntax as the Unicode string syntax --- see
On 4/14/09, Peter Eisentraut pete...@gmx.net wrote:
On Saturday 11 April 2009 00:54:25 Tom Lane wrote:
It gets worse though: I have seldom seen such a badly designed piece of
syntax as the Unicode string syntax --- see
When postgreSQL is compiled with --thread-safe that libpq should be
thread safe. But it is not true when somebody call fork(). The problem
is that fork() forks only active threads and some mutex can stay locked
by another thread. We use ssl_config mutex which is global.
We need implement atfork
Cast of aggregate's type works:
# select avg(s)::int4 from foo;
but that doesn't work for with new windowing functions interface:
# select avg(s)::int4 OVER () from foo;
ERROR: syntax error at or near OVER
LINE 1: select avg(s)::int4 OVER () from foo;
Is that intentional?
--
Teodor Sigaev
2009/4/14 Teodor Sigaev teo...@sigaev.ru:
select avg(s)::int4 OVER () from foo;
You can put the cast outside the window expression such as:
postgres=# select s,(avg(s) OVER (range between unbounded preceding
and current row))::int4 from foo;
s | avg
---+-
1 | 2
2 | 2
3 | 2
(3
Fujii Masao escreveu:
Is it worth making the patch which creates stats_temp_directory
if not present?
+1.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Teodor Sigaev teo...@sigaev.ru writes:
Cast of aggregate's type works:
# select avg(s)::int4 from foo;
but that doesn't work for with new windowing functions interface:
# select avg(s)::int4 OVER () from foo;
ERROR: syntax error at or near OVER
LINE 1: select avg(s)::int4 OVER () from foo;
Greg Stark st...@enterprisedb.com writes:
However, I'm kind of confused by that result. Why does the range
between unbounded preceding and current row seem to be doing the
average of the whole result set?
That's what it's supposed to do. Current row really includes all peers
of the current row
On 4/14/09, Peter Eisentraut pete...@gmx.net wrote:
On Tuesday 14 April 2009 14:38:38 Marko Kreen wrote:
I think the problem is that they should not act like E'' strings, but they
should act like plain '' strings - they should follow stdstr setting.
That way existing tools that may
Pavel Stehule pavel.steh...@gmail.com wrote:
I though about it too. But I am not sure, if this isn't too
complicated solution for simple task. If I thing little bit more -
main important is timestamp of last change.
Yeah, if it would be too heavy to add a timestamp column or two to
pg_class
Peter Eisentraut pete...@gmx.net writes:
On Saturday 11 April 2009 00:54:25 Tom Lane wrote:
If we let this go into 8.4, our previous rounds with security holes
caused by careless string parsing will look like a day at the beach.
Note that the escape character marks the Unicode escapes; it
On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Pavel Stehule pavel.steh...@gmail.com wrote:
I though about it too. But I am not sure, if this isn't too
complicated solution for simple task. If I thing little bit more -
main important is timestamp of last
On Mon, 2009-04-13 at 15:31 -0400, Tom Lane wrote:
I'm getting the following failure on RHEL 4:
http://www.gunduz.org/temp/regression.out
http://www.gunduz.org/temp/regression.diffs
This test is checking whether you have working 64-bit-tzdata support.
It seems you don't.
If you
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
On Mon, 2009-04-13 at 15:31 -0400, Tom Lane wrote:
This test is checking whether you have working 64-bit-tzdata support.
It seems you don't.
So what changed between 8.3 and 8.4? Same box can build 8.3 with
--with-system-tzdata .
Marko Kreen wrote:
I still stand on my proposal, how about extending E'' strings with
unicode escapes (eg. \u)? The E'' strings are already more
clearly defined than '' and they are our own, we don't need to
consider random standards, but can consider our sanity.
I suspect there
On Monday 13 April 2009 22:39:58 Andrew Dunstan wrote:
Umm, but isn't that because your encoding is using one code point?
See the OP's explanation w.r.t. canonical equivalence.
This isn't about the number of bytes, but about whether or not we should
count characters encoded as two or more
On Tuesday 14 April 2009 07:07:27 Andrew Gierth wrote:
FWIW, the SQL spec puts the onus of normalization squarely on the
application; the database is allowed to assume that Unicode strings
are already normalized, is allowed to behave in implementation-defined
ways when presented with strings
On Tue, Apr 14, 2009 at 1:32 PM, Peter Eisentraut pete...@gmx.net wrote:
On Monday 13 April 2009 22:39:58 Andrew Dunstan wrote:
Umm, but isn't that because your encoding is using one code point?
See the OP's explanation w.r.t. canonical equivalence.
This isn't about the number of bytes, but
Marko Kreen mark...@gmail.com writes:
I would prefer that such quoting extensions would wait until
stdstr=on setting is the only mode Postgres will operate.
Fitting new quoting ways to environment with flippable stdstr setting
will be rather painful for everyone.
It would certainly be a lot
On Tuesday 14 April 2009 14:38:38 Marko Kreen wrote:
I think the problem is that they should not act like E'' strings, but they
should act like plain '' strings - they should follow stdstr setting.
That way existing tools that may (or may not..) understand E'' and stdstr
settings, but
On Saturday 11 April 2009 18:20:47 Sam Mason wrote:
I can't see much support in the other database engines; searched for
Oracle, MS-SQL, DB2 and Firebird. MySQL has it planned for 7.1, so not
for a while.
DB2 supports it, as far as I know.
--
Sent via pgsql-hackers mailing list
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
Yeah, if it would be too heavy to add a timestamp column or two to
pg_class and maybe one or two others, why is it better to add a whole
new table to maintain in parallel -- with it's own primary key,
David Fetter da...@fetter.org writes:
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
I'd go for something like
Type
window
agg
trigger
normal
Or we could spell out aggregate, but that makes the column a
couple of characters wider ...
Done.
I had a second thought about
Greg Stark st...@enterprisedb.com writes:
What's really at issue is what is a string?. That is, it a sequence
of characters or a sequence of code points. If it's the former then we
would also have to prohibit certain strings such as U'\0301'
entirely. And we have to make substr() pick out the
On Tue, Apr 14, 2009 at 12:35:21PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
I'd go for something like
Type
window
agg
trigger
normal
Or we could spell out aggregate, but that makes the column a
On Apr 14, 2009, at 9:26 AM, Tom Lane wrote:
Another question is what is the purpose of a database? To me it
would
be quite the wrong thing for the DB to not store what is presented, as
long as it's considered legal. Normalization of legal variant forms
seems pretty questionable. So I'm
On Tue, Apr 14, 2009 at 8:53 AM, Peter Eisentraut pete...@gmx.net wrote:
This doesn't excite me. I think the tendency should be to get rid of E''
usage, because its definition of escape sequences is single-byte and ASCII
centric and thus overall a legacy construct. Certainly, we will want to
David E. Wheeler wrote:
On Apr 14, 2009, at 9:26 AM, Tom Lane wrote:
Another question is what is the purpose of a database? To me it would
be quite the wrong thing for the DB to not store what is presented, as
long as it's considered legal. Normalization of legal variant forms
seems pretty
Kevin Grittner wrote:
I'm curious -- can every multi-code-point character be normalized to a
single-code-point character?
I don't believe so. Those combinations used in the most common
orthographic languages have their own code points, but I understand you
can use the combining
On Tue, 2009-04-14 at 11:16 -0400, Tom Lane wrote:
So what changed between 8.3 and 8.4? Same box can build 8.3 with
--with-system-tzdata .
We didn't have 64-bit tzdata support before --- it's a new test
covering new functionality.
Thanks Tom.
Regards,
--
Devrim GÜNDÜZ, RHCE
Robert Haas robertmh...@gmail.com wrote:
Making pg_class and pg_proc tables larger hurts run-time
performance,
potentially. Making a separate table only slows down DDL
operations,
which are much less frequent.
Copying the pg_class table, with oids and indexes, with and without
the addition
Andrew Dunstan and...@dunslane.net writes:
I think there's a good case for some functions implementing the various
Unicode normalization functions, though.
I have no objection to that so long as the code footprint is in line
with the utility gain (i.e. not all that much). If we have to bring
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
the timestamp column caused the copy to be about 11.3% larger
Grabbed the wrong numbers. It's really 2.5%, but still
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Greg Stark st...@enterprisedb.com wrote:
Peter Eisentraut pete...@gmx.net wrote:
SELECT U'\00E9', char_length(U'\00E9');
?column? | char_length
--+-
é| 1
(1 row)
SELECT U'\0065\0301', char_length(U'\0065\0301');
?column? | char_length
On Tuesday 14 April 2009 18:49:45 Greg Stark wrote:
What's really at issue is what is a string?. That is, it a sequence
of characters or a sequence of code points.
I think a sequence of codepoints would be about as silly a definition as the
antiquated notion of a string as a sequence of bytes.
On Monday 13 April 2009 20:18:31 - - wrote:
2) PG has no support for the Unicode collation algorithm. Collation is
offloaded to the OS, which makes this quite inflexible.
This argument is unclear. Do you want the Unicode collation algorithm or do
you want flexibility? Some OS do implement
On Tuesday 14 April 2009 19:26:41 Tom Lane wrote:
Another question is what is the purpose of a database? To me it would
be quite the wrong thing for the DB to not store what is presented, as
long as it's considered legal. Normalization of legal variant forms
seems pretty questionable. So
Robert Haas robertmh...@gmail.com writes:
Maybe I've just got my head deeply in the sand, but I don't understand
what the alternative to E'' supposedly is. How am I supposed to write
the equivalent of E'\t\n\f' without using E''? The
standard_conforming_strings syntax apparently supports no
I don't believe that the standard forbids the use of combining chars at all.
RFC 3629 says:
... This issue is amenable to solutions based on Unicode Normalization
Forms, see [UAX15].
This is the relevant part. Tom was claiming that the UTF8 encoding required
normalizing the string of
I've been following the thread with growing lack of understanding why
this is so hardly discussed, and I went back to the documentation of
what the restore_command should do (
http://www.postgresql.org/docs/8.3/static/warm-standby.html )
While the algorithm presented in the pseudocode isn't
On Tuesday 14 April 2009 20:35:21 Robert Haas wrote:
Maybe I've just got my head deeply in the sand, but I don't understand
what the alternative to E'' supposedly is. How am I supposed to write
the equivalent of E'\t\n\f' without using E''?
Well, the first alternative is to type those
On Apr 14, 2009, at 11:22 AM, Tom Lane wrote:
BTW, does anyone know whether Unicode includes the ASCII control
characters ... ie, is \u0009 a name for tab? If so, maybe this
syntax is in part an attempt to cover that use-case in the standard.
Yes, you can use, e.g., #x0009; in HTML to
On Apr 14, 2009, at 11:10 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a good case for some functions implementing the
various
Unicode normalization functions, though.
I have no objection to that so long as the code footprint is in line
with the utility
On Tuesday 14 April 2009 17:13:00 Marko Kreen wrote:
If the parsing does not happen in 2 passes and it does not take account
of stdstr setting then the default breakage would be:
stdstr=off, U' \' UESCAPE '!'.
I think we can handle that and the cases Tom presents by erroring out when the
On Tuesday 14 April 2009 21:22:29 Tom Lane wrote:
BTW, does anyone know whether Unicode includes the ASCII control
characters ... ie, is \u0009 a name for tab? If so, maybe this
syntax is in part an attempt to cover that use-case in the standard.
Yes on both.
--
Sent via pgsql-hackers
On Tue, Apr 14, 2009 at 2:13 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
the timestamp column caused the copy to be about 11.3% larger
Grabbed the wrong numbers. It's really 2.5%, but still
Well, that's why Tom doesn't want to
On Tuesday 14 April 2009 18:54:33 Tom Lane wrote:
The other proposal that seemed
attractive to me was a decode-like function:
uescape('foo\00e9bar')
uescape('foo\00e9bar', '\')
This was discussed previously, but rejected with the following argument:
There are some other
On Tuesday 14 April 2009 17:32:00 Tom Lane wrote:
I admit that the SQL:2008 way also covers Unicode code
points in identifiers, which we can't emulate without a lexical change;
but frankly I think the use-case for that is so thin as to be almost
nonexistent. Who is going to choose
Peter Eisentraut pete...@gmx.net writes:
I think we can handle that and the cases Tom presents by erroring out
when the U syntax is used with stdstr off.
I think you're missing the point --- this is not about whether the
syntax is unambiguous (it is already) but about whether a frontend that
On Tue, Apr 14, 2009 at 2:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Maybe I've just got my head deeply in the sand, but I don't understand
what the alternative to E'' supposedly is. How am I supposed to write
the equivalent of E'\t\n\f' without using
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 18:54:33 Tom Lane wrote:
The other proposal that seemed
attractive to me was a decode-like function:
uescape('foo\00e9bar')
uescape('foo\00e9bar', '\')
This was discussed previously, but rejected with the following
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be better
to make the aggregate case be aggregate and take the width hit.
Otherwise translators are going to be puzzled when they come across
agg as a
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be
better to make the aggregate case be aggregate and take the
width hit.
David Fetter wrote:
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
I think it's good to have them translatable. As for using
aggregate instead of agg I don't think it's that great an idea.
If you need to notify translators that agg stands for aggregate,
add a /*
On Tue, Apr 14, 2009 at 03:04:55PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
I think it's good to have them translatable. As for using
aggregate instead of agg I don't think it's that great an
idea. If you need
On Tuesday 14 April 2009 21:48:12 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I think we can handle that and the cases Tom presents by erroring out
when the U syntax is used with stdstr off.
I think you're missing the point --- this is not about whether the
syntax is
Meredith L. Patterson m...@osogato.com writes:
Tom Lane wrote:
I suspect that it's actually impossible to parse such a thing correctly
without a full-fledged flex lexer or something of equivalent complexity.
Is there a reason not to use a full-fledged flex lexer?
The point is that that's a
Tom Lane wrote:
I suspect that it's actually impossible to parse such a thing correctly
without a full-fledged flex lexer or something of equivalent complexity.
Certainly it's a couple of orders of magnitude harder than it is for
either standard-conforming or E'' literals.
Is there a reason
Tom Lane wrote:
This is *not* about code within Postgres.
One typically provides libraries for this sort of thing, but your point
is taken; suggestion withdrawn.
--mlp
_
Meredith L. Patterson
Founder and CTO
Osogato, Inc.
--
Sent via pgsql-hackers mailing list
On 4/14/09, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 18:54:33 Tom Lane wrote:
The other proposal that seemed
attractive to me was a decode-like function:
uescape('foo\00e9bar')
uescape('foo\00e9bar', '\')
This was
Whichever way the current discussion about Unicode literals turns out,
it's clear that plpgsql is not up to speed on matching the core lexer's
behavior --- it's wrong anyway with respect to
standard_conforming_strings.
I had earlier speculated semi-facetiously about ripping out the plpgsql
lexer
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
There are some issues:
* Is it possible to determine the platform encoding?
There is no platform encoding in linux. File name encoding depend on user
locale, so different users can have different encoding of file name.
--
Sergey
On Tue, Apr 14, 2009 at 2:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, that's fine, but that's a long way from Peter's statement that
I think the tendency should be to get rid of E'' usage.
Bear in mind that that's Peter's opinion; it's not
On Tue, Apr 14, 2009 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whichever way the current discussion about Unicode literals turns out,
it's clear that plpgsql is not up to speed on matching the core lexer's
behavior --- it's wrong anyway with respect to
standard_conforming_strings.
I had
Hi,
On Wed, Apr 8, 2009 at 9:11 PM, I wrote:
Following the discussion here
http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
, I wrote a small patch which rotates the last XLog file on shutdown
[snip]
Any comment or advice on how I can fix it with a different
On Tue, 2009-04-14 at 16:37 -0400, Tom Lane wrote:
Comments, objections, better ideas?
Please, if you do this, make it optional.
Potentially changing the behaviour of thousands of functions just to fix
a rare bug will not endear us to our users. The bug may be something
that people are relying
Robert Haas wrote:
All this sounds good. As for how to handle := and .., I think making
them lex the same way in PL/pgsql and core SQL would be a good thing.
They don't have any significance in core SQL. What would we do with the
lexeme?
ISTR we've used some hacks in the past to
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
All this sounds good. As for how to handle := and .., I think making
them lex the same way in PL/pgsql and core SQL would be a good thing.
They don't have any significance in core SQL. What would we do with the
lexeme?
It would
Hi,
I built PG 8.4 beta1 on 2 different Fedora-10 boxes. One of them was a
local box, which runs under QEMU. The other one is Fedora's build
servers. (I did a scratch build on Fedora build server)
On the first machine, I got a regression failure:
http://www.gunduz.org/temp/regression.out
On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
I had a second thought about that: presumably we should make the
function type names translatable. If we do that, it might be better
to make the aggregate case be aggregate and take the width hit.
Otherwise
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-04-14 at 16:37 -0400, Tom Lane wrote:
Comments, objections, better ideas?
Please, if you do this, make it optional.
I don't think making the plpgsql lexer pluggable is realistic.
Potentially changing the behaviour of thousands of
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
I built PG 8.4 beta1 on 2 different Fedora-10 boxes. One of them was a
local box, which runs under QEMU. The other one is Fedora's build
servers. (I did a scratch build on Fedora build server)
On the first machine, I got a
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
this my proposal is very simple. It help to people who have to manage
large or complex database system. Important data are date of creating
and date of altering tables and stored procedures. These data cannot
be modified by
Peter == Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 07:07:27 Andrew Gierth wrote:
FWIW, the SQL spec puts the onus of normalization squarely on the
application; the database is allowed to assume that Unicode
strings are already normalized, is allowed to behave in
Bruce Momjian br...@momjian.us writes:
How do you handle dump/restore? Is it preserved?
I would think not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-04-14 at 16:37 -0400, Tom Lane wrote:
Comments, objections, better ideas?
Please, if you do this, make it optional.
I don't think making the plpgsql lexer pluggable is realistic.
Potentially changing the
Bruce Momjian br...@momjian.us writes:
Well, this bug has existed long before 8.4 so we could just leave it for
8.5, and it is not like we have had tons of complaints; the only
complaint I saw was one from March, 2008.
We had one last week, which is what prompted me to start looking at the
* Bruce Momjian (br...@momjian.us) wrote:
Well, this bug has existed long before 8.4 so we could just leave it for
8.5, and it is not like we have had tons of complaints; the only
complaint I saw was one from March, 2008.
I think it's a good thing to do in general. I'm also concerned about
Here is a WIP patch to solve server-side encoding issues.
It includes Solution of the file name problem of copy on windows patch.
http://archives.postgresql.org/message-id/20090413184335.39be.52131...@oss.ntt.co.jp
It could solve the following issues. They are not only in Windows nor
Hi all,
I'm doing an experimental project using Postgres as the prototype.
I want to store attribute values of xml type in an internal XML table
which is created for every XML column. One XML node (element,
attribute or text) is stored as a tuple in the XML table. While
a 127MB XML document
85 matches
Mail list logo
