"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 at
"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
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
> proba
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
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 LIM
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 restrict
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
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 ...
> >
> >
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 d
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 ther
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 f
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).
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
> >argum
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 bes
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 LI
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
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?
> >
>
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 wi
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
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 joinin
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 :)
---(en
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 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
--
25 matches
Mail list logo
