Re: Variable LIMIT and OFFSET in SELECTs
От | Richard Huxton |
---|---|
Тема | Re: Variable LIMIT and OFFSET in SELECTs |
Дата | |
Msg-id | 473C9DD1.3060402@archonet.com обсуждение исходный текст |
Ответ на | Re: Variable LIMIT and OFFSET in SELECTs (Reg Me Please <regmeplease@gmail.com>) |
Ответы |
Re: Variable LIMIT and OFFSET in SELECTs
Re: Variable LIMIT and OFFSET in SELECTs |
Список | pgsql-general |
Reg Me Please wrote: > Sorry but I don't understand. > > Either the LIMIT and OFFSET are to be definitely CONSTANT or not. They must be constant during the execution of the query. > In the SQL function body the LIMIT and the OFFSET *are definitely not* > CONSTANT. And the planner can do its job at best as usual. Well, they're constant during one execution of the query, but I grant you the planner doesn't know what values they will have. > As Sam says I should be able to "put an IMMUTABLE expression into a LIMIT or > OFFSET". And under some circumstances (SQL function body) it's true even with > VARIABLE expressions like function call arguments. And you can. CREATE FUNCTION limfunc() RETURNS integer AS 'SELECT 2' LANGUAGE SQL IMMUTABLE; SELECT * FROM fit LIMIT limfunc(); a | b ---+---- 1 | 43 2 | 43 (2 rows) > In my opinion I would say it's more a problem with the syntax checker that > with the planner ("semantics" in my lingo). But I could be wrong. Well, what it won't let you do is have a subquery in the LIMIT clause. That's probably due to a combination of: 1. The spec probably says something about it 2. There is an obvious approach involving functions/prepared queries 3. You're the first person to have asked for it. Now if you can get a couple of hundred to join you at #3, you might have a feature request :-) -- Richard Huxton Archonet Ltd
В списке pgsql-general по дате отправления: