Re: [BUGS] Prepared Statement Name Truncation - Mailing list pgsql-general

From Gavan Schneider
Subject Re: [BUGS] Prepared Statement Name Truncation
Date
Msg-id 12628-1353281537-663381@sneakemail.com
Whole thread Raw
In response to Re: [BUGS] Prepared Statement Name Truncation  (David Johnston <polobo@yahoo.com>)
List pgsql-general
On Sunday, November 18, 2012 at 01:10, David Johnston wrote:

>
> Can the system be made smart enough to not allow intra-schema
> collisions in addition to same schema ones?  That would seem to be the
> area of greatest concern - particularly around the usage of
> truncate/delete/drop.
>
>
My summary FWIW:
1. Potential exists for internally generated names to exceed maxlen; and
2. this maxlen is shorter than the SQL standard specification; but
3. it may not be worth the performance hit to be SQL compliant in this; with
4. potential for (undetected) name collision and unintended consequences.

May I suggest an idea from the days when memory was counted in (tiny int) kB:
    represent the over maxlen identifiers "as is" up to maxlen-8 bytes
    use those last 8 bytes for a 40bit hash in Base32 for disambiguation
and,
    if 1:10^^12 residual collision risk is considered too high
    a side list of overlong names would allow for a second hash disambiguation process.

Notes:
1.  The choice of Base32 encoding may be a matter of personal preference
    <http://en.wikipedia.org/wiki/Base32>, and, if so, I suggest using the
    Crockford encoding <http://www.crockford.com/wrmg/base32.html>.
    (I am impressed his design is excellent, while also averting some
    accidental obscenities. None of the others offer this feature :)
2.  Something along these lines, with the side table to track the
    (hopefully) occasional overlong identifiers, could give standards
    compliance in identifier length while still keeping the working
    tables compact.
3.  (Wild speculation) There may be a "sweet spot" using even shorter
    identifiers than is the case now, with full disambiguation, which
    might improve overall performance.

Regards
Gavan Schneider



pgsql-general by date:

Previous
From: Vick Khera
Date:
Subject: Re: Difference between varchar and text?
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Parser - Query Analyser