Please note - I'm not trying to pick up a fight.
Tom Lane wrote:
>
> Your source appears fairly ignorant of things-float.
That is possible, and even likely, however
> If they really are
> using decimal FP, it's easy to demonstrate that a lossless conversion
> to/from binary representation of simil
Magnus Hagander wrote:
Andrew Dunstan wrote:
mastodon and skylark just failed at the make stage due to a thinko on my
part (now fixed). However, this is not correctly caught by the buildfarm
script, meaning that the process invoked at this stage ('build 2>&1') is
not exiting properly with a
Andrew Dunstan wrote:
>
> mastodon and skylark just failed at the make stage due to a thinko on my
> part (now fixed). However, this is not correctly caught by the buildfarm
> script, meaning that the process invoked at this stage ('build 2>&1') is
> not exiting properly with a non-zero status on
On 5/23/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> As an amusing side note, I have heard a claim that the only reason we
> need endianity at all is because the Europeans didn't understand that
> Arabic is written from right to left. In Arabic you read "17" as "seven
> and ten", which
Tom Lane wrote:
Yeah. It seems we need three comparison functions after all:
Yeah, that was my confusion. I thought we had concluded that we didn't,
but clearly we do.
1. Single-byte character set: needs NextByte and ByteEq only.
2. Generic multi-byte character set: both % and _ must
On Tue, May 22, 2007 at 12:12:51PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > ... It turns out (according to the analysis) that the
> > only time we actually need to use NextChar is when we are matching an
> > "_" in a like/ilike pattern.
> I thought we'd determined t
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2007-05-22, Tom Lane <[EMAIL PROTECTED]> wrote:
>> If "%" advances by bytes then this will find a spurious match. The
>> only thing that prevents it is if "B" can't be both a leading and a
>> trailing byte of validly-encoded MB characters.
> Whi
On 2007-05-22, Tom Lane <[EMAIL PROTECTED]> wrote:
> If "%" advances by bytes then this will find a spurious match. The
> only thing that prevents it is if "B" can't be both a leading and a
> trailing byte of validly-encoded MB characters.
Which is (by design) true in UTF8, but is not true of mos
On 5/22/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But before I commit this I'd appreciate seeing some more testing, both
for correctness and performance.
Any chance the patch applies cleanly on a 8.2 code base? I can test it
on a real life 8.2 db but I won't have the time to load the data i
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I would concur with a patch that ensures that this is what happens
>> on the different ARM variants ... though I'll still be interested
>> to see how you make that happen given the rather poor visibility
>> into which model and endian
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I thought we'd determined that advancing bytewise for "%" was also
>> risky, in two cases:
>>
>> 1. Multibyte character set that is not UTF8 (more specifically, does not
>> have a guarantee that first bytes and not-first bytes are di
On Tue, May 22, 2007 at 05:14:54PM +0300, Shachar Shemesh wrote:
> As an amusing side note, I have heard a claim that the only reason we
> need endianity at all is because the Europeans didn't understand that
> Arabic is written from right to left. In Arabic you read "17" as "seven
> and ten", whic
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... It turns out (according to the analysis) that the only time we
actually need to use NextChar is when we are matching an "_" in a
like/ilike pattern.
I thought we'd determined that advancing bytewi
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
... It turns out (according to the analysis) that the
only time we actually need to use NextChar is when we are matching an
"_" in a like/ilike pattern.
I thought we'd determined that advancing bytewise for "%" was also risk
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ... It turns out (according to the analysis) that the
> only time we actually need to use NextChar is when we are matching an
> "_" in a like/ilike pattern.
I thought we'd determined that advancing bytewise for "%" was also risky,
in two cases:
1. Mu
Starting from a review of a patch from Itagaki Takahiro to improve LIKE
performance for UTF8-encoded databases, I have been working on improving
both efficiency of the LIKE/ILIKE code and the code quality.
The main efficiency improvement comes from some fairly tricky analysis
and discussion
adam terrey <[EMAIL PROTECTED]> writes at
http://archives.postgresql.org/pgsql-bugs/2007-05/msg00187.php
> Anyway, mybug: I have a test SELECT statement (Listing A - see "sql
> listings.txt") wich produces different results under two simular setups
> (Listing B and Listing C). Each setup should
Florian G. Pflug wrote:
Is there consensus what the correct behaviour should be for
self-referential updates in read-committed mode? Does the SQL Spec
have anything to say about this?
This seems to have gone all quiet. Do we need a TODO to keep a note of
it? Just "correct behaviour for self-r
Tom Lane wrote:
> Okay, I spent some time googling this question, and I can't find any
> suggestion that any ARM variant uses non-IEEE-compliant float format.
> What *is* real clear is that depending on ARM model and a run time (!)
> CPU endianness flag, there are three or four different possibilit
19 matches
Mail list logo
