| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs? |
| Date: | 2011-08-16 11:23:48 |
| Message-ID: | 4E4A5344.7040004@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08/16/2011 04:56 AM, Magnus Hagander wrote:
> On Mon, Aug 15, 2011 at 23:49, Greg Stark<stark(at)mit(dot)edu> wrote:
>> On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... and that would be a seriously bad API. There are not SUSET
>>> restrictions on other resources such as work_mem. Why do we need
>>> one for this?
>> I think a better analogy would be imposing a maximum number of rows a
>> query can output. That might be a sane thing to have for some
>> circumstances but it's not useful in general.
> Uh. You mean like LIMIT, which we already have?
There is no LIMIT imposed on a query by a server setting, which would be
the right analogy here.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-08-16 12:04:37 | Re: WIP: Fast GiST index build |
| Previous Message | Anssi Kääriäinen | 2011-08-16 10:24:25 | Re: index-only scans |