Re: [HACKERS] SELECT ... LIMIT (trial implementation)
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] SELECT ... LIMIT (trial implementation) |
Дата | |
Msg-id | m0zUz52-000EBPC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] SELECT ... LIMIT (trial implementation) (Terry Mackintosh <terry@terrym.com>) |
Ответы |
Re: [HACKERS] SELECT ... LIMIT (trial implementation)
|
Список | pgsql-hackers |
> > On Sun, 18 Oct 1998, Tom Lane wrote: > > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > > What if someone wants the rows from 500 to the end. Should we allow > > > the syntax to be: > > > SELECT ... [LIMIT count] [OFFSET offset] > > > LIMIT and OFFSET are independent. > > > > I like that syntax the best, but remember we are not inventing in > > a green field here. Isn't this a feature that already exists in > > other DBMs? We should probably copy their syntax, unless it's > > truly spectacularly awful... > > > > regards, tom lane > > None that I have used (VFP, M$ SQL Server) that had 'LIMIT', had 'OFFSET'. > So it would seem that the very idea of OFFSET is to break with what others > are doing. > > I too like the above syntax. > Why mimic, when you can do better? Go for it! > We have a powerful parser. So we can provide ... [ LIMIT { rows | ALL } ] [ OFFSET skip ] or ... [ LIMIT [ skip , ] { rows | ALL } ] at the same time. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: