Re: [pgsql-admin] "Soft-hitting" the 1600 column limit

From: Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
To: nunks <nunks(dot)lol(at)gmail(dot)com>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: [pgsql-admin] "Soft-hitting" the 1600 column limit
Date: 2018-06-06 16:53:15
Message-ID: CAOC+FBXehj4X2DMfytnPKHRWrWWZjq1G9OfUXsMop5Tex7hrvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

let's just stop for a moment and talk about what you're doing that requires
*1600 columns* because my jaw is hitting the floor.

On Wed, Jun 6, 2018 at 9:39 AM, nunks <nunks(dot)lol(at)gmail(dot)com> wrote:

> Hello!
>
> I'm trying to support an application in production at work, and for some
> obscure reason the developer made it drop and re-create a column
> periodically.
>
> I know this is a bad practice (to say the least), and I'm telling them to
> fix it, but after the 1600th drop/add cycle, PostgreSQL starts giving out
> the column limit error:
>
> ERROR: tables can have at most 1600 columns
>
> I reproduced this behavior in PostgreSQL 10.3 with a simple bash loop and
> a two-column table, one of which is fixed and the other is repeatedly
> dropped and re-created until the 1600 limit is reached.
>
> To me this is pretty cool, since I can use this limit as leverage to push
> the developers to the right path, but should Postgres be doing that? It's
> as if it doesn't decrement some counter when a column is dropped.
>
> Many thanks!
> Bruno
>
> ----------
> “Life beats down and crushes the soul and art reminds you that you have
> one.”
>
> - Stella Adler
>

--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Scott Ribe 2018-06-06 16:56:49 Re: [pgsql-admin] "Soft-hitting" the 1600 column limit
Previous Message Tom Lane 2018-06-06 16:51:56 Re: [pgsql-admin] "Soft-hitting" the 1600 column limit