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 late
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"
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 tha
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-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, b
