Re: pg_generate_sequence and info_schema patch (Was: SELECT Question) - Mailing list pgsql-patches

From Tom Lane
Subject Re: pg_generate_sequence and info_schema patch (Was: SELECT Question)
Date
Msg-id 2094.1075669961@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_generate_sequence and info_schema patch (Was: SELECT  (Joe Conway <mail@joeconway.com>)
Responses Re: pg_generate_sequence and info_schema patch (Was: SELECT
List pgsql-patches
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> Joe Conway <mail@joeconway.com> writes:
>>> regression=# select * from pg_generate_sequence(8, 4);
>>> ERROR:  finish is less than start
>>
>> Hm, would it be better just to return an empty set?  Certainly I'd
>> expect pg_generate_sequence(1,0) to return an empty set with no error.

> OK -- for this and other concerns below, I bit the bullet and decided to
> support descending series and step sizes other than one. Now it does this:

> regression=# select * from generate_series(8, 4);
>   generate_series
> -----------------
>                 8
>                 7
>                 6
>                 5
>                 4
> (5 rows)

And how do I get a zero-size set out of it?  I think it's a really bad
idea to silently assume descending is meant if start > finish --- that
will create boundary-case bugs in many scenarios.  A looping construct
that cannot iterate zero times is broken and dangerous (see Fortran DO
loops for context ... folklore has it that Mariner II was lost to
exactly such a bug).

If you want to allow the 3-parameter form to specify a negative step
size, that's fine.  But don't use a heuristic to guess the intended
step direction.

> p.s. I did a `make distclean` prior to creating the attached diff. Do
> the lines at the top, e.g.:
>    ? src/bin/pg_id/.deps
>    ? src/bin/pg_id/pg_id
>    ...
> indicate stuff not being cleaned up when it ought to be?

Something odd there.  The src/bin/pg_id subdirectory should be entirely
gone in recent checkouts, and I'm not sure why you're seeing .so files
still laying about but they shouldn't be there either ...

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for psql startup clarity
Next
From: Claudio Natoli
Date:
Subject: Re: pg_generate_sequence and info_schema patch (Was: SE