On Tue, 2009-04-14 at 18:29 -0400, Tom Lane wrote:
> Simon Riggs 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.
Doesn't so
Hi,
On Tue, Apr 14, 2009 at 10:26 PM, Euler Taveira de Oliveira
wrote:
> Fujii Masao escreveu:
>>
>> Is it worth making the patch which creates stats_temp_directory
>> if not present?
>>
> +1.
Here is the patch.
This patch should be added to CommitFest-2009-First?,
or committed before 8.4 relea
Euler Taveira de Oliveira wrote:
> Fujii Masao escreveu:
> > Is it worth making the patch which creates stats_temp_directory
> > if not present?
> >
> +1.
+1, but AFAIK stats_temp_directory was designed to symlink to a RAM drive.
Even if stats_temp_directory exists as a symbolic link, the dest
Hi,
On Wed, Apr 15, 2009 at 3:30 AM, Andreas Pflug
wrote:
> 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.
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 'dblp.
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
Japan-
* 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
Bruce Momjian 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
plpgsql lexer si
Tom Lane wrote:
> Simon Riggs 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 th
Bruce Momjian 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:
http://www.postgresql.org/mailpref/pgsql-hackers
> "Peter" == Peter Eisentraut 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
>>
Tom Lane wrote:
> Pavel Stehule 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 user, so implement
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= 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 regression failure:
>
Simon Riggs 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 functions just to fix
>
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.
>
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
http://
Andrew Dunstan 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 just fail --
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 spli
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
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 me
On Tue, Apr 14, 2009 at 4:37 PM, Tom Lane 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 earlier spec
On Tue, Apr 14, 2009 at 2:55 PM, Tom Lane wrote:
> Robert Haas 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 necessarily shared
> by anyone else.
Itagaki Takahiro 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 Burladyan
--
Sent via pgsql-ha
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 a
On 4/14/09, Tom Lane wrote:
> Peter Eisentraut 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 prev
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 (pgsql-hacke
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 reaso
"Meredith L. Patterson" 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 pretty lar
On Tuesday 14 April 2009 21:48:12 Tom Lane wrote:
> Peter Eisentraut 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
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
> > > ide
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",
> >
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
Robert Haas 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 necessarily shared
by anyone else. I was just responding to your assertion of the
diametricall
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
Peter Eisentraut 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 argument:
>
On Tue, Apr 14, 2009 at 2:22 PM, Tom Lane wrote:
> Robert Haas 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_
Peter Eisentraut 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
doesn't underst
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 identif
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 Tue, Apr 14, 2009 at 2:13 PM, Kevin Grittner
wrote:
> "Kevin Grittner" 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 add it to pg_class. But putting
it in a separate
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 mai
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
On Apr 14, 2009, at 11:10 AM, Tom Lane wrote:
Andrew Dunstan 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 tha
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., in HTML to represent a 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 chara
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 dealin
>> 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 st
Robert Haas 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 escapes of
> any k
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.
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 t
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 byt
Greg Stark wrote:
> Peter Eisentraut 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
>> --+-
>
"Kevin Grittner" 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:
http://www.postgresql.org/ma
Andrew Dunstan 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 in
ICU or somethin
Robert Haas 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 of one timestamp co
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
devr
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 chars
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 prett
On Tue, Apr 14, 2009 at 8:53 AM, Peter Eisentraut 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 keep
> around
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 w
On Tue, Apr 14, 2009 at 12:35:21PM -0400, Tom Lane wrote:
> David Fetter 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 m
Greg Stark 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 right number of
David Fetter 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 thoug
Robert Haas 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,
>> foreign keys (
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 (pgsql-hac
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 def
Marko Kreen 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 safer to wait u
On Tue, Apr 14, 2009 at 1:32 PM, Peter Eisentraut 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 about
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 string
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 mo
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 wo
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= 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 .
We didn't h
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.
>
>
On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
wrote:
> Pavel Stehule 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
Peter Eisentraut 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 doesn't
> aff
Pavel Stehule 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 and maybe one or two
On 4/14/09, Peter Eisentraut 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 (or may n
Greg Stark 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 in the window f
Teodor Sigaev 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;
> Is th
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:
http://www.postgresql
2009/4/14 Teodor Sigaev :
> 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 rows)
However, I'm
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
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 ha
On 4/14/09, Peter Eisentraut 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
> > http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL
>
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 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.or
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,
Hi,
On Tue, Apr 14, 2009 at 6:35 PM, Simon Riggs 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 executed.
>>
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 d
Hi,
On Mon, Apr 13, 2009 at 2:52 PM, Fujii Masao 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, the tri
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
90 matches
Mail list logo
