Reg Me Please [EMAIL PROTECTED] writes:
Of course, in my opinion at least, there's no real reason for the above
syntax limitation, as the sematics is not.
Is not what? Is not sensible?
create or replace function f_limoff_1( l int, o int )
returns setof atable as $$
select * from atable
Tom Lane [EMAIL PROTECTED] writes:
Sam Mason [EMAIL PROTECTED] writes:
In relational algebra terms, try thinking about what would happen if you
did something like:
SELECT * FROM foo LIMIT val;
Where the table foo has more than one row (and val had different values
for each row). Which
Il Friday 16 November 2007 08:33:14 Tom Lane ha scritto:
Reg Me Please [EMAIL PROTECTED] writes:
The OP's complaint is that we don't allow a variable of the query's own
level, but AFAICT he's still not grasped the point that that leads to an
indeterminate limit value ...
So it works,
Sam Mason [EMAIL PROTECTED] writes:
wow, that's kind of fun isn't it. I only thought you could put a
constant in there. Maybe I should have had a look in the grammar/tested
it first!
IIRC, it used to be restricted to a constant, a few revisions back.
In current releases the only restriction
On 11/16/07, Reg Me Please [EMAIL PROTECTED] wrote:
Il Friday 16 November 2007 08:33:14 Tom Lane ha scritto:
Let me try to explain one more time. You propose allowing
select ... from
table1 join table2 on table1.x = table2.y
limit table1.z
Now this would be
Reg Me Please wrote:
Il Thursday 15 November 2007 20:28:17 hai scritto:
Reg Me Please wrote:
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
On Fri, Nov 16, 2007 at 01:38:30AM -0500, Tom Lane wrote:
Sam Mason [EMAIL PROTECTED] writes:
wow, that's kind of fun isn't it. I only thought you could put a
constant in there. Maybe I should have had a look in the grammar/tested
it first!
IIRC, it used to be restricted to a constant,
Il Thursday 15 November 2007 14:09:16 Trevor Talbot ha scritto:
On 11/15/07, Reg Me Please [EMAIL PROTECTED] wrote:
In any case, what'd be the benefit for not allowing variables as LIMIT
and OFFSET argument?
When you can fully describe the semantics of your example, you'll
probably be able
Reg Me Please [EMAIL PROTECTED] writes:
create table limoff( l int, o int );
insert into limoff values ( 10,2 );
select a.* from atable a,limoff limit l offset o;
I am truly curious what you think the semantics of that ought to be.
regards, tom lane
Hello
LIMIT has impact on execution plan, so there cannot be variables. Use
SRF function and dynamic statements instead.
Regards
Pavel
On 15/11/2007, Reg Me Please [EMAIL PROTECTED] wrote:
In any case, what'd be the benefit for not allowing variables as LIMIT and
OFFSET argument?
--
Reg me
On 11/15/07, Reg Me Please [EMAIL PROTECTED] wrote:
In any case, what'd be the benefit for not allowing variables as LIMIT and
OFFSET argument?
When you can fully describe the semantics of your example, you'll
probably be able to answer that question too :)
---(end of
In any case, what'd be the benefit for not allowing variables as LIMIT and
OFFSET argument?
--
Reg me Please
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
Il Thursday 15 November 2007 17:55:42 Sam Mason ha scritto:
On Thu, Nov 15, 2007 at 05:34:43PM +0100, Reg Me Please wrote:
Il Thursday 15 November 2007 14:09:16 Trevor Talbot ha scritto:
On 11/15/07, Reg Me Please [EMAIL PROTECTED] wrote:
In any case, what'd be the benefit for not
Sam Mason [EMAIL PROTECTED] writes:
On Thu, Nov 15, 2007 at 06:08:20PM +0100, Reg Me Please wrote:
But then why allowing the LIMIT and the OFFSET as coming from function
argument evaluations?
I believe the query is planned by ignoring the LIMIT and OFFSET.
No, it still knows there will be a
On Thu, Nov 15, 2007 at 06:08:20PM +0100, Reg Me Please wrote:
Your remarks make a lot of sense. Of course.
good! it's interesting to see how things like this fit together.
But then why allowing the LIMIT and the OFFSET as coming from function
argument evaluations?
I believe the query is
Sam Mason [EMAIL PROTECTED] writes:
In relational algebra terms, try thinking about what would happen if you
did something like:
SELECT * FROM foo LIMIT val;
Where the table foo has more than one row (and val had different values
for each row). Which row would the database use? I
On Thu, Nov 15, 2007 at 05:34:43PM +0100, Reg Me Please wrote:
Il Thursday 15 November 2007 14:09:16 Trevor Talbot ha scritto:
On 11/15/07, Reg Me Please [EMAIL PROTECTED] wrote:
In any case, what'd be the benefit for not allowing variables as LIMIT
and OFFSET argument?
When you can
Il Thursday 15 November 2007 20:28:17 hai scritto:
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
Sorry but I don't understand.
Either the LIMIT and OFFSET are to be definitely CONSTANT or not.
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.
As Sam says I should be able to put an IMMUTABLE expression into a
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
On Thu, Nov 15, 2007 at 07:28:17PM +, Richard Huxton wrote:
Reg Me Please wrote:
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.
Reg Me Please [EMAIL PROTECTED] writes:
The OP's complaint is that we don't allow a variable of the query's own
level, but AFAICT he's still not grasped the point that that leads to an
indeterminate limit value ...
So it works, but it's not serious enough to be unlocked.
You really don't
Il Friday 16 November 2007 07:38:30 Tom Lane ha scritto:
IIRC, it used to be restricted to a constant, a few revisions back.
In current releases the only restriction that stems from laziness is
not allowing a sub-select. (If anyone were to put forward a serious
use-case, we'd probably go fix
Il Thursday 15 November 2007 23:08:10 Richard Huxton ha scritto:
Reg Me Please wrote:
Il Thursday 15 November 2007 20:28:17 hai scritto:
Reg Me Please wrote:
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
Sam Mason [EMAIL PROTECTED] writes:
On Fri, Nov 16, 2007 at 01:38:30AM -0500, Tom Lane wrote:
IIRC, it used to be restricted to a constant, a few revisions back.
I'm amazed it supports anything more than a constant. The values are
almost always going to come from external code, so there
Hi all.
I'd need to implement a parametric windowed select over a table
called atable. The idea is to have a one row table to maintain
the LIMIT and the OFFSET for the selects. If I try this:
create table limoff( l int, o int );
insert into limoff values ( 10,2 );
select a.* from atable a,limoff
26 matches
Mail list logo
