Re: Revisiting NAMEDATALEN

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Emrul <emrul(at)emrul(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Revisiting NAMEDATALEN
Date: 2017-07-03 18:36:37
Message-ID: edc8edb5-24c0-8950-820e-c9fb5bfbc501@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/03/2017 11:31 AM, Emrul wrote:
> Hi hackers,
>
> This question came up again on Reddit:
> https://www.reddit.com/r/PostgreSQL/comments/6kyyev/i_have_hit_the_table_name_length_limit_a_number/
> and I thought I'd echo it here.
>
> I totally am on board with short, descriptive names and a good convention.
> However, there are just so many cases where 63 characters can't
> descriptively describe a column name. I've been on projects where we have
> one table maybe with only a few thousand records but hundreds of columns
> each uniquely describing an attribute on the record. It is a challenge
> bordering on impossible to fit them into a consistently named field of <63
> characters that someone can later refer to and know what piece of
> information it actually refers to.
>
> Is this something that can be revisited for an upcoming release? Also, are
> there any technical problems that would be created by increasing this
> attribute?

Although I appreciate the sentiment this seems over the top:

datasystem_adjustmentmanagement_mm_datasystem_adjustmentmanagement_products

You can always use COMMENT ON to explode the actual meaning.

JD

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Emrul 2017-07-03 18:46:51 Re: Revisiting NAMEDATALEN
Previous Message Emrul 2017-07-03 18:31:01 Revisiting NAMEDATALEN