Skip site navigation (1) Skip section navigation (2)

Re: keyword LIMIT in SQL-statement, psqlodbc workaround?

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Johann Zuschlag <zuschlag2(at)online(dot)de>
Cc: "Pgsql-interfaces(at)postgresql(dot)org" <Pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: keyword LIMIT in SQL-statement, psqlodbc workaround?
Date: 2000-12-23 01:16:30
Message-ID: Pine.LNX.4.30.0012230205440.1505-100000@peter.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Johann Zuschlag writes:

> I'm using a commercial application. Well, apart from the problem
> that it crashes my psqlodbc.dll (which I'm trying to debug)
> it uses the keyword LIMIT.
> To my knowledge it worked with PostgreSQL 6.4. Why not with 7.x?

Not sure what was going on in 6.4 but LIMIT is a key word at least since
7.0.  The reason that this is so is the difficulty parsing commands like

	SELECT 'xxx' && LIMIT 5;
When the parser is there it does not know whether && is an infix or
postfix operator, in other words whether LIMIT is an operand (as it could
potentially be if your LIMIT column ever needs to be selected) or a
separate clause.  This could perhaps be fixed with more than one token
lookahead and some sweat, but it hasn't been done.

> I thought it should be possible. Did I misinterpret SQL-92/98?
> MS-SQL and ORACLE are accepting it.

It's not part of SQL, but ORACLE has a similar clause IIRC.

> Since I can't persuade my application to put LIMIT in quotes,
> I need another solution. Any ideas, workarounds how to do it in
> psqlodbc?

You could try rebuilding PostgreSQL with LIMIT renamed to something like
XYZLIMIT (look into src/backend/parser), but that strikes me as a brute
force hack.

Peter Eisentraut      peter_e(at)gmx(dot)net

In response to

pgsql-interfaces by date

Next:From: Michael SimsDate: 2000-12-23 01:22:49
Subject: Re: ODBC on Solaris
Previous:From: Peter EisentrautDate: 2000-12-23 01:04:37
Subject: Re: ODBC on Solaris

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group