possible issue with array type created for every heap relation composite type

From: Jimmy Yih <jyih(at)pivotal(dot)io>
To: pgsql-hackers(at)postgresql(dot)org
Subject: possible issue with array type created for every heap relation composite type
Date: 2018-07-10 22:33:41
Message-ID: CAOMx_OChjvsCeqJh1prJHyOxefgYPs1NUvEZphGX_k2dwGLG4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

In Postgres 8.3, it was decided that an array type would be automatically
created for every heap relation's composite type.

Reference thread:
https://www.postgresql.org/message-id/flat/20070302234016.GF3665%40fetter.org

The possible issue I would like to note is related to how the array type is
named in makeArrayTypeName() function. The composite type will take the
heap relation's relname as its typname and the array type will usually be
named with an underscore prepended (after first attempting to use the
relname and hitting typname collision with the composite type). If the
typname with the underscore prepended is already taken, the logic is to
continue prepending underscores until there are no typname collisions
(truncating the end of the typname if typname gets past NAMEDATALEN of
64). It is possible that enough heap relations with similar relnames could
cause more and more typname collisions until you end up with typnames that
primarily consist of underscores or not being able to construct a typname
because we have reached a typname consisting of all underscores (which can
cause table creation failure).

This is more likely to happen when heap relnames are similar and of string
length 63+. I can see this possibly being an issue with table partitioning
if a user decides on partition names that reach string length 63+ (assuming
user uses exactly 63 characters or does not hit relation already exists
from relname truncation). This may also become an issue if we ever decide
to do automated partition naming instead of having the user naming the
partitions manually.

Is this an issue we should be worrying about? When and how often are array
types of heap relation's composite type used (I can only think of doing
array_agg on table rows)? Should we consider coding up "CREATE TYPE foo
ARRAY OF bar" as suggested in the past in the above referenced hackers
thread?

Attached are some SQL examples describing this issue.

Thanks,
Jimmy

Attachment Content-Type Size
typname_collision.sql application/octet-stream 5.9 KB
typname_collision_with_partitioning.sql application/octet-stream 15.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-07-10 22:44:21 Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Previous Message Tom Lane 2018-07-10 22:31:15 CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?