On Fri, 2007-04-27 at 04:09 -0400, Tom Lane wrote:
I feel uncomfortable about this proposal because it will compute
different hashes for values that differ only in having different
numbers of trailing zeroes. Now the numeric.c code is supposed to
suppress extra trailing zeroes on output, but
Sorry for fat-fingering the previous reply -- I wanted to add:
On Fri, 2007-04-27 at 10:02 -0400, Tom Lane wrote:
Perhaps a sufficiently robust way would be to form the hash as the
XOR of each supplied digit, circular-shifted by say 3 times the
digit's weight.
The only objection I have to
On Fri, 2007-04-20 at 09:46 +0200, Pavel Stehule wrote:
I refreshed Magnus's patch
http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
februar.
Applied, thanks.
BTW, I notice that the documentation for PL/PgSQL's FETCH command states
that only the direction variants that
Neil Conway [EMAIL PROTECTED] writes:
BTW, I notice that the documentation for PL/PgSQL's FETCH command states
that only the direction variants that fetch a *single* row are allowed.
This is not actually the case: FETCH RELATIVE 2 FROM c INTO v results in
assigning the first row from c into v,
I would argue that we should likewise not allow them in plpgsql's MOVE,
although this is more of a judgment call than is the case for FETCH.
I just don't think it's a good idea to provide two redundant ways to do
the same thing, when we might want to make one of the ways mean
something else
