Re: [HACKERS] Re: [SQL] Column name's length

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jwieck(at)debis(dot)com (Jan Wieck)
Cc: lockhart(at)alumni(dot)caltech(dot)edu (Thomas Lockhart), pgsql-hackers(at)postgreSQL(dot)org, zalman(at)netcom(dot)com
Subject: Re: [HACKERS] Re: [SQL] Column name's length
Date: 1999-06-02 13:41:56
Message-ID: 24896.928330916@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

wieck(at)debis(dot)com (Jan Wieck) writes:
> What about building them from the tables OID plus the column
> numbers.

The parser doesn't know what OID will be assigned to the table at the
time it builds the names for the derived objects. I suppose we could
postpone the creation of these names until after the table OID is known,
but that looks like a rather large and risky change to be making at this
stage of the release cycle...

At this point I like Zalman's idea, which if I understood it properly
went like this:

1. If table and column name are short enough, use "table_column_key"
etc (so, no change in the cases that the system accepts now).

2. Otherwise, truncate table and/or column name to fit, leaving room for
a few extra characters that are made from a hash of the removed
characters. The result would look something like "tab_col_5927_key".

This still isn't a 100% solution, but it's probably a 99.5% solution
where the simple truncation idea would be maybe 95%. Not sure that
the additional coverage is worth making the names harder to predict
for a person, though.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-06-02 14:34:05 Re: [HACKERS] Re: [SQL] Column name's length
Previous Message Tom Lane 1999-06-02 13:16:57 Re: [HACKERS] Re: [SQL] Column name's length