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. *****
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 |