Postgres Pro
Downloads
Home   >   mailing lists

Thread: LIMIT QUESTION

LIMIT QUESTION

From
"Martin Wong"
Date:
Hi,

I've an elementary question. What's wrong with the following :

dbtest=> select * from testusers limit 10;
ERROR:  parser: parse error at or near "10"
dbtest=> select version();
version
-------------------------------------------------------------
PostgreSQL 6.4.2 on i586-pc-linux-gnu, compiled by gcc 2.7.2.
(1 row)

the testuser table has about 1000 rows.

Please comment.

Thanks

Re: [GENERAL] LIMIT QUESTION

From
Chris Bitmead
Date:
Only PostgreSQL 6.5 Beta supports LIMIT.

> I've an elementary question. What's wrong with the following :
>
> dbtest=> select * from testusers limit 10;
> ERROR:  parser: parse error at or near "10"
> dbtest=> select version();
> version
> -------------------------------------------------------------
> PostgreSQL 6.4.2 on i586-pc-linux-gnu, compiled by gcc 2.7.2.
> (1 row)
>
> the testuser table has about 1000 rows.
>
> Please comment.
>
> Thanks

Re: [GENERAL] LIMIT QUESTION

From
José Soares
Date:
Chris Bitmead ha scritto:

> Only PostgreSQL 6.5 Beta supports LIMIT.
>
> > I've an elementary question. What's wrong with the following :
> >
> > dbtest=> select * from testusers limit 10;
> > ERROR:  parser: parse error at or near "10"
> > dbtest=> select version();
> > version
> > -------------------------------------------------------------
> > PostgreSQL 6.4.2 on i586-pc-linux-gnu, compiled by gcc 2.7.2.
> > (1 row)
> >
> > the testuser table has about 1000 rows.
> >
> > Please comment.
> >
> > Thanks

Use SET QUERY_LIMT TO 10;
this should work in 6.4.2
______________________________________________________________
PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'

Re: [GENERAL] LIMIT QUESTION

From
Margarita Barvinok
Date:
This works in 6.4.2:

set QUERY_LIMIT TO '10';     or
set QUERY_LIMIT = '10';

On Thu, 29 Apr 1999, [iso-8859-1] Jos� Soares wrote:

>
> Use SET QUERY_LIMT TO 10;
> this should work in 6.4.2
> ______________________________________________________________
> PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Jose'
>
>
>
>

serious bug in "alter table tbname rename to newname"

From
jim@reptiles.org (Jim Mercer)
Date:
============================================================================
                        POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name               : Jim Mercer
Your email address      : jim@reptiles.org

Category                : runtime: back-end
Severity                : critical

Summary: alter table tabname rename to newname does not rename extra files

System Configuration
--------------------
  Operating System   : FreeBSD 2.x/3.x

  PostgreSQL version : 6.4 and 6.4.2

  Compiler used      : gcc

Hardware:
---------
Pentium 128M ram
FreeBSD bigbird.nag.ca 3.0-RELEASE FreeBSD 3.0-RELEASE #1: Tue Feb  2 22:50:41 EST 1999
root@bigbird.nag.ca:/usr/src/sys/compile/BIGBIRD i386 


Versions of other tools:
------------------------


--------------------------------------------------------------------------

Problem Description:
--------------------
when a table exceeds 2gb, it appears that postgres will create subfiles for the data.
when you rename a table, the sub files do no get renamed.
see backend/commands/rename.c [renamerel()]

--------------------------------------------------------------------------

Test Case:
----------
create a table in excess of 2gig, which in turn creates subfiles
in data/base/tabname.
rename the table.
the subfiles are not renamed.


--------------------------------------------------------------------------

Solution:
---------
possible solution is to check if the table has subfiles, look for those subfiles and rename them as well.


--------------------------------------------------------------------------


--
[ Jim Mercer    Reptilian Research      jim@reptiles.org   +1 416 410-5633 ]
[ The telephone, for those of you who  have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail.            ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]