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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: IN question


  • From: Josh Berkus <josh(at)agliodbs(dot)com>
  • To: Jeff Davis <pgsql(at)j-davis(dot)com>
  • Cc: Neil Conway <nrc(at)cs(dot)berkeley(dot)edu>, Steve Atkins <steve(at)blighty(dot)com>, SF PostgreSQL <sfpug(at)postgresql(dot)org>
  • Subject: Re: IN question
  • Date: Thu, 11 Dec 2008 10:05:35 -0800
  • Message-id: <4941566F.9000606@agliodbs.com> <text/plain>

Jeff Davis wrote:
On Wed, 2008-12-10 at 16:11 -0800, Neil Conway wrote:
On Wed, Dec 10, 2008 at 3:39 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
And if it's additional memory, it should probably be a different GUC.
Measuring the limit in bytes makes no sense, anyway.


Sure it does. If you're concerned about the application generating
infinite SQL strings and sending them to the server, a byte limit on the
SQL string would solve it.

After all, as Josh pointed out, there _is_ a limit measured in bytes:
available memory (and some operating systems don't handle that very
well).

Yes. For example, if the length of your query exceeds any of various memory limits on Linux, the connection crashes with a very unfriendly error message. If it was our limit, the error message could at least be friendly: "Query string too long. Please edit the query or increase work_mem."

And infinite SQL isn't hypothetical; just 4 weeks ago I fixed a problem for a client which turned out to be their home-baked ORM building IN() clauses up to 150,000 values long.

--Josh



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group