2010/8/2 Pavel Stehule :
> 2010/7/31 Robert Haas :
>> On Sat, Jul 31, 2010 at 8:10 AM, Peter Eisentraut wrote:
>>> On fre, 2010-07-30 at 12:50 +0100, Mike Fowler wrote:
> * xml_is_well_formed returns true for simple text
>
> postgres=# SELECT xml_is_well_formed('');
> xml
On Sun, 2010-08-01 at 21:57 -0400, Robert Haas wrote:
> On Fri, Jul 16, 2010 at 1:19 AM, Jeff Davis wrote:
> > Thank you for the review.
> >
> > On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote:
> >> (1) Exclusion constraints support for operators where "x x"
> >> is false (tiny patch)
>
On Tue, Jul 13, 2010 at 1:25 PM, Peter Eisentraut wrote:
> Here is a proof of concept for per-column collation support.
>
Hi,
i was looking at this.
nowadays, CREATE DATABASE has a lc_collate clause. is the new collate
clause similar as the lc_collate?
i mean, is lc_collate what we will use as
2010/7/31 Robert Haas :
> On Sat, Jul 31, 2010 at 8:10 AM, Peter Eisentraut wrote:
>> On fre, 2010-07-30 at 12:50 +0100, Mike Fowler wrote:
>>> > * xml_is_well_formed returns true for simple text
>>> >
>>> > postgres=# SELECT xml_is_well_formed('');
>>> > xml_is_well_formed
>>> > ---
On Sun, Aug 1, 2010 at 9:40 PM, Tom Lane wrote:
> I'm still wondering about the bleats I saw for -fwrapv though.
> configure already is set up to install that switch only conditionally:
>
> # Disable optimizations that assume no overflow; needed for gcc 4.3+
> PGAC_PROG_CC_CFLAGS_OPT([-fwrapv])
On Sun, Aug 1, 2010 at 7:40 PM, Tom Lane wrote:
> I tried to duplicate your results using what I believe to be the latest
> version of clang,
I'm using SVN tip of llvm+clang from ~one week ago.
>> (2) clang doesn't support (or require) "-no-cpp-precomp", which
>> src/template/darwin adds to $CC
Neil Conway writes:
> (As an aside, is "no-cpp-precomp" still necessary for
> reasonably-modern versions of Apple GCC?)
I looked into this point a little bit. Apple abandoned their
nonstandard precompiler as of gcc 3.3, so the switch is a no-op
in that version and later, as per release notes her
On Sun, Aug 1, 2010 at 4:53 PM, Pavel Stehule wrote:
> a) remove special row number handling of plpgsql (first patch)
Committed.
> b) more robust algorithm for header rows identification
Have not gotten to this one yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
Neil Conway writes:
> I tried $subject recently, and noticed some minor issues:
I tried to duplicate your results using what I believe to be the latest
version of clang,
$ clang -v
Apple clang version 1.5 (tags/Apple/clang-60)
Target: x86_64-apple-darwin10
Thread model: posix
(this is a 10.6.4
On Sun, Aug 1, 2010 at 10:08 PM, Fujii Masao wrote:
> On Sun, Aug 1, 2010 at 9:30 PM, Greg Stark wrote:
>> This doesn't have to be done manually.
>
> Agreed, if we register standbys in the master.
>
>> The streaming protocol could
>> include the standby sending its system id to the master. The ma
On Sun, Aug 1, 2010 at 9:30 PM, Greg Stark wrote:
> This doesn't have to be done manually.
Agreed, if we register standbys in the master.
> The streaming protocol could
> include the standby sending its system id to the master. The master
> could just keep a list of system ids with the last reco
On Fri, Jul 16, 2010 at 1:19 AM, Jeff Davis wrote:
> Thank you for the review.
>
> On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote:
>> (1) Exclusion constraints support for operators where "x x"
>> is false (tiny patch)
>> https://commitfest.postgresql.org/action/patch_view?id=307
>> (2
On Fri, Jul 30, 2010 at 1:14 PM, Alexander Korotkov
wrote:
> Ok, here is the patch for multi-byte characters.
> I changed arguments of levenshtein_internal function from text * to const
> char * and int. I think that it makes levenshtein_internal more reusable.
> For example, this function can be
Neil Conway writes:
> *** src/backend/utils/adt/datetime.c 9 May 2010 02:15:59 - 1.212
> --- src/backend/utils/adt/datetime.c 1 Aug 2010 23:09:30 -
> ***
> *** 3098,3104
> break;
>
Neil Conway writes:
> I tried $subject recently, and noticed some minor issues:
> (1) Two warnings that suggest bugs; in src/backend/utils/adt,
> datetime.c:3101:27: warning: use of logical || with constant operand;
> switch to bitwise | or remove constant
> And similarly for src/interfaces/ecpg
I tried $subject recently, and noticed some minor issues:
(1) Two warnings that suggest bugs; in src/backend/utils/adt,
datetime.c:3101:27: warning: use of logical || with constant operand;
switch to bitwise | or remove constant
And similarly for src/interfaces/ecpg/pgtypeslib/interval.c. Attach
Hi Pavel,
Currently your patch isn't applying to head, from the looks of things a
function signature has changed. Can you update your patch please?
Also, having had a read through the patch itself I note that there are
no tests and no changes to documentation. Shouldn't the documentation
adv
Hello
I am sending a modified patch - changes:
a) remove special row number handling of plpgsql (first patch)
b) more robust algorithm for header rows identification
Regards
Pavel Stehule
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> Pavel Stehule writes:
>>> s
I wrote:
> Robert Haas writes:
>> Yeah, maybe you're right. But I'd still prefer to see us break the
>> ABI and do this just in 9.0 rather than changing 8.4.
> OK, I can live with that. I'll take a look at it shortly.
Proposed patch attached (compiles, untested as yet).
Robert Haas writes:
> On Sun, Aug 1, 2010 at 11:35 AM, Tom Lane wrote:
>> Personally, rather than sweat about what the exact definition of line
>> numbers is, I think we should be moving further in the direction of
>> being able to regurgitate source text to identify error locations.
> I basical
Currently the english parser in text search does not support multiple
words in the same position. Consider a word "wikipedia.org". The text
search would return a single token "wikipedia.org". However if someone
searches for "wikipedia org" then there will not be a match. There are
two problems here
On Sun, Aug 1, 2010 at 11:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>>> The need to count lines manually in function definitions is
>>> far less than it was back when that kluge was put in.
>
>> Why?
>
> That hack goes back to plpgsql's preh
Robert Haas writes:
> On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane wrote:
>> I don't think this can be claimed to be a corner case. If you set up
>> an FTS index according to the first alternative offered in
>>
>> http://developer.postgresql.org/pgdocs/postgres/textsearch-tables.html#TEXTSEARCH-T
Robert Haas writes:
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> The need to count lines manually in function definitions is
>> far less than it was back when that kluge was put in.
> Why?
That hack goes back to plpgsql's prehistory (it's there, though sans
comment, in plpgsql's scan.l
Tom Lane wrote:
Robert Haas writes:
>> I guess I'd appreciate it if someone could explain in more detail
>> in what cases we fail to collect stats.
> [detailed description]
> I don't think this can be claimed to be a corner case. If you set
> up an FTS index according to the first alternati
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> Pavel Stehule writes:
>>> so my plan
>>
>>> a) fix problem with ambiguous $function* like you proposed
>>> b) fix problem with "first row excepting" - I can activate a detection
>>> only for plpgsql language - I can iden
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of sáb jul 31 09:57:13 -0400 2010:
>> So far as I can see, it's impossible to handle this situation when
>> examining only one TID per stream with no lookahead. Choosing to
>> advance the second stream would obviously fail in many other c
On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> so my plan
>
>> a) fix problem with ambiguous $function* like you proposed
>> b) fix problem with "first row excepting" - I can activate a detection
>> only for plpgsql language - I can identify LANGUAGE before.
>
> Ick.
On Sun, Aug 1, 2010 at 6:54 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I have committed this patch with a few changes.
>
> Thanks.
>
>> First, I felt that there was little point in showing this detail
>> only in verbose mode; indeed, it seems like that could be confusing
>> in some circums
Pavel Stehule writes:
> so my plan
> a) fix problem with ambiguous $function* like you proposed
> b) fix problem with "first row excepting" - I can activate a detection
> only for plpgsql language - I can identify LANGUAGE before.
Ick. We should absolutely NOT have a client-side special case fo
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 12:15 AM, Pavel Stehule
> wrote:
>> 2010/8/1 Robert Haas :
>>> On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule
>>> wrote:
> I'm setting this as ready for committer.
Thank you very much
>>>
>>> I took a look at this tonight and am a b
On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane wrote:
> Now, of the above the only cases where we'd be likely to be able to do
> anything very useful with stats on the expression value are the name
> case, which isn't that exciting in practice, and the tsvector cases.
> For tsvector it was only with 8
On Sun, Aug 1, 2010 at 8:30 AM, Greg Stark wrote:
> On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas
> wrote:
>> In fact, it's possible for one standby to sync up to X, then disconnect and
>> reconnect, and have the master count it second time in the quorum.
>> Especially if the master doesn't
On Sun, Aug 1, 2010 at 12:15 AM, Pavel Stehule wrote:
> 2010/8/1 Robert Haas :
>> On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule
>> wrote:
I'm setting this as ready for committer.
>>>
>>> Thank you very much
>>
>> I took a look at this tonight and am a bit mystified by the following bit:
>
On Sun, Aug 1, 2010 at 7:11 AM, Heikki Linnakangas
wrote:
> In fact, it's possible for one standby to sync up to X, then disconnect and
> reconnect, and have the master count it second time in the quorum.
> Especially if the master doesn't notice that the standby disconnected, e.g a
> network prob
Robert Haas wrote:
> I have committed this patch with a few changes.
Thanks.
> First, I felt that there was little point in showing this detail
> only in verbose mode; indeed, it seems like that could be confusing
> in some circumstances. (I thought I checked this was an index not
> a const
On 27/07/10 16:12, Joshua Tolley wrote:
My concern is that in a quorum system, if the quorum number is less than the
total number of replicas, there's no way to know *which* replicas composed the
quorum for any given transaction, so we can't know which servers to fail to if
the master dies.
In
37 matches
Mail list logo
