From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Kris Jurka <books(at)ejurka(dot)com>, Alex <alex(at)meerkatsoft(dot)com>, "Lada 'Ray' Lostak" <ray(at)unreal64(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: SELECT Question |
Date: | 2003-11-20 17:45:51 |
Message-ID: | 5344.1069350351@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Kris Jurka wrote:
>> A useful generic function would be one something like range(min,max) that
>> would return a set of rows so you wouldn't have to actually have a table.
> You mean like this?
> CREATE OR REPLACE FUNCTION test(int,int) RETURNS SETOF int AS '
> BEGIN
> FOR i IN $1..$2 LOOP
> RETURN NEXT i;
> END LOOP;
> RETURN;
> END;
> ' LANGUAGE 'plpgsql' STRICT IMMUTABLE;
I was thinking of proposing that we provide something just about like
that as a standard function (written in C, not in plpgsql, so that it
would be available whether or not you'd installed plpgsql). There are
some places in the information_schema that desperately need it ---
right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
some of the information_schema views, which means they are broken if
one changes that #define. We could fix this if we had a function like
the above and exported FUNC_MAX_ARGS as a read-only GUC variable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-11-20 17:56:00 | Re: SELECT Question |
Previous Message | konf | 2003-11-20 17:40:18 | Re: tsearch2 installation |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-11-20 17:56:00 | Re: SELECT Question |
Previous Message | Tom Lane | 2003-11-20 16:34:11 | Re: cleanup execTuples.c |