Re: How to find LIMIT in SQL standard

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to find LIMIT in SQL standard
Date: 2003-09-22 15:59:33
Message-ID: 20030922084734.P2590@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 22 Sep 2003, Rory Campbell-Lange wrote:

> I have to file a bug about the implementation of some delivery report
> database calls in the Kannel (open source WAP/SMS) server code.
>
> Essentially the call (as defined below) asks for an update and adds a
> LIMIT parameter on the end of the UPDATE. (eg update where x=1 limit 1).
> Postgres doesn't like this and I assume it isn't SQL standards
> compliant and need to refer to this in my bug report.

Well, for SQL92, it looks like the correct section to start in is
13.10 (update statement: searched) which looks like:

UPDATE <table name>
SET <set clause list>
WHERE <search condition>

The last of those is the interesting one which is 8.12 (search condition)

<search condition> ::=
<boolean term>
| <search condition> OR <boolean term>

<boolean term> ::=
<boolean factor>
| <boolean term> AND <boolean factor>

<boolean factor> ::=
[ NOT ] <boolean test>

<boolean test> ::=
<boolean primary> [ IS [ NOT ] <truth value> ]

<truth value> ::=
TRUE
| FALSE
| UNKNOWN

<boolean primary> ::=
<predicate>
| <left paren> <search condition> <right paren>

Then 8.1 (predicate)

<predicate> ::=
<comparison predicate>
| <between predicate>
| <in predicate>
| <like predicate>
| <null predicate>
| <quantified comparison predicate>
| <exists predicate>
| <unique predicate>
| <match predicate>
| <overlaps predicate>

Also, since tables are effectively unordered, unless the other
where conditions are guaranteed to get a single row anyway which
row is modified is fairly indeterminate; this is only interesting
because it means that you don't necessarily get the same row
as a previous select (if any) would get. That's not always important,
but since update also has no way to order the rows that I know of,
if it were important you couldn't really get around it.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message victor silalahi 2003-09-22 16:08:38 DSN-Less
Previous Message victor silalahi 2003-09-22 15:55:29 DSN-LESS