Re: [HACKERS] SELECT ... LIMIT (trial implementation)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] SELECT ... LIMIT (trial implementation) |
Дата | |
Msg-id | 199810180347.XAA18823@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] SELECT ... LIMIT (trial implementation) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] SELECT ... LIMIT (trial implementation)
|
Список | pgsql-hackers |
> jwieck@debis.com (Jan Wieck) writes: > > I've seen the queryLimit by SET variable stuff and that > > really can break rewrite rules, triggers or functions. This > > is because the query limit will be inherited by any query > > (inserts, updates, deletes too) done by them. > > [ example snipped ] > > This is a feature where users can get around rules that > > ensure data integrity. > > Ouch. I think this point is a *fatal* objection to implementing > query limit as a SET variable. That might be a quick-and-dirty way > of getting some functionality going, but we can't let it loose on the > world like that. OK, I assume you are saying that you like LIMIT/OFFSET in the query, but not as a SET command that could be unreliable. Jan has already coded a much more reliable, user-friently way, by putting the LIMIT/OFFSET in the query, and I think that is the way to go too. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: