Re: [HACKERS] Arrays of Complex Types - Mailing list pgsql-patches

On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > One of the things that's been bothering me about this proposal is that
> > it leaves untouched and indeed greatly expands the scope of the typename
> > mangling we do. (i.e. adding an entry to pg_type with _ prepended).
>
> Yeah, that's been bothering me too.  One of the problems with the patch
> as-is is that it extends the 62-instead-of-63-char limit to table names
> as well as type names.

I did this by copying some code which already creates array names, so
should that code change to do something different, the
62-instead-of-63-char thing would go away along with it.  I agree that
the prepended _s are far from optimal.

> I've been thinking of proposing that we add a column to pg_type that
> points from a type to its array type (if any), ie the reverse link
> from typelem.  If we had that then the parser could follow that to
> determine which type is foo[], instead of relying on the _foo naming
> convention.  I don't suggest that we stop using the naming convention,
> but it would no longer be a hard-and-fast rule, just a convention.

That'd be neat :)

> In particular we could rejigger things around the edges to reduce
> the name conflict problem.  For instance the rule for forming array type
> names could be "prepend _, truncate to less than 64 bytes if necessary,
> then substitute numbers at the end if needed to get something unique".
> This is not all that different from what we do now to get unique
> serial sequence names, for example.
>
> This would also open the door to supporting
>
> CREATE TYPE foo AS ARRAY OF bar

I'm sorry to keep harping on this, but I really don't see a use case
and do see foot guns both with making the array types optional and
with decoupling their names from those of their respective compound
types.  When they're optional, we get all kinds of "stepping on a step
that isn't there" issues, and when they're decoupled, operations like,
"ALTER TABLE foo RENAME TO bar" have either surprising or undefined
behavior, or both.

> without having to have any restrictions about the name of foo.
> I'd still much rather do things that way for arrays of composites
> than invent a ton of pg_type entries that are mostly going to go
> unused.

I'm sure there's a better way than my first attempt.

> PS: Has anyone looked at what it will take to make the entries in an
> array-of-composite be something smaller than full tuples?  It's not
> going to be anything but a toy unless you can get the per-entry
> overhead down to something sane.  Perhaps the MinimalTuple
> representation would work.

Sounds neat, too :)

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate