Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Also it would get more buildfarm coverage if it were default. If it
> breaks something we'll notice earlier.
Since nothing the regression tests do even approach 1GB, the odds that
the buildfarm will notice problems are approximately zero.
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > > There is latest version of nonsegment support patch. I changed
> > > LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> > > -disable-segmented-files switch to configure. I kept tuplestore behavior
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Applied with minor corrections.
> Why is this not the default when supported?
Fear.
Maybe eventually, but right now I think it's too risky.
One point that I already found out the hard way is that sizeof(off_t) = 8
does not guaran
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > There is latest version of nonsegment support patch. I changed
> > LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> > -disable-segmented-files switch to configure. I kept tuplestore behavior
> > and it still split file in bo
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> There is latest version of nonsegment support patch. I changed
> LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added
> -disable-segmented-files switch to configure. I kept tuplestore behavior
> and it still split file in both mode.
Applied with
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Another question that occurred to me - did you try using strpbrk() to
look for the next interesting character rather than your homegrown
searcher gadget? If so, how did that perform?
It looks like strpbrk() performs poorly:
Yes, not surpris
Andrew Dunstan wrote:
Another question that occurred to me - did you try using strpbrk() to
look for the next interesting character rather than your homegrown
searcher gadget? If so, how did that perform?
It looks like strpbrk() performs poorly:
unpatched:
testname | min duration
--
Right now I see an significant advantage of such layer: two possible
extension of dictionary (filtering and storing original form) are
One more extension: drop too long words. For example, decrease limit of max
length of word to prevent long to be indexed - word with 100 characters is
suspic
Well, if you think this can/should be done somewhere outside the
dictionary, should I revert the applied patch?
No, that patch is about case sensitivity of synonym dictionary. I suppose, Simon
wants to replace 'bill' to 'account', but doesn't want to get 'account Clinton'
For another dictiona
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Hmm, I can see how some middleware would help with folding or not
>> folding the input token, but what about the words coming from the
>> dictionary file (particularly the *output* lexeme)? It's not apparent
>> to me that it's sensible to try to control
Hmm, I can see how some middleware would help with folding or not
folding the input token, but what about the words coming from the
dictionary file (particularly the *output* lexeme)? It's not apparent
to me that it's sensible to try to control that from outside the
dictionary.
Right now I see
Tom Lane wrote:
This patch seems broken in a number of ways. Why are you removing
-DLINUX_PROFILE, for example? Are you sure you don't need -D_GNU_SOURCE?
And why add -DSUNOS4_CC, which is a Solaris-specific define (not that
we seem to be using it anywhere anymore)? Do we really have to have a
Andrew Dunstan wrote:
>
>
> Simon Riggs wrote:
> > As Greg mentions on another thread, not all patches are *intended* to be
> > production quality by their authors. Many patches are shared for the
> > purpose of eliciting general feedback. You yourself encourage a group
> > development approach a
On Mon, 2008-03-10 at 10:01 -0400, Tom Lane wrote:
> In future perhaps I should take it as a given that
> Simon doesn't expect his patches to be applied?
I think you should take it as a given that Simon would like to try to
work together, sharing ideas and code, without insults and public
derisio
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Sun, 9 Mar 2008, Tom Lane wrote:
>> Would a similar parameter be useful for any of the other dictionary
>> types?
> There are many things desirable to do with dictionaries, for example,
> say dictionary to return an original word plus it's normal form
On Mon, 2008-03-10 at 09:42 -0400, Andrew Dunstan wrote:
> I think if you post something marked Work In Progress, there is an
> implied commitment on your part to post something complete at a later stage.
>
> So if it's forgotten you would be the one doing the forgetting. ;-)
But if they aren't
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think if you post something marked Work In Progress, there is an
> implied commitment on your part to post something complete at a later stage.
It *wasn't* marked Work In Progress, and Simon went out of his way to
cross-post it to -patches, where the
Simon Riggs wrote:
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yours
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > As Greg mentions on another thread, not all patches are *intended* to be
> > production quality by their authors. Many patches are shared for the
> > purpose of eliciting general feedback. You yourself encourage a
Kris Jurka <[EMAIL PROTECTED]> writes:
> The tsvector code is printing a pointer difference as an integer,
> generating the following warning:
> tsvector.c: In function 'tsvectorin':
> tsvector.c:225: warning: format '%d' expects type 'int', but argument 2
> has type 'long int'
> I was thinking
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You yourself encourage a group
development approach and specifically punish those people droppi
On Sun, 2008-03-09 at 23:03 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I've coded a small patch to allow CaseSensitive synonyms.
>
> Applied with corrections (it'd be good if you at least pretended to test
> stuff before submitting it).
It is a frequent accusation of you
22 matches
Mail list logo
