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

From Andrew Dunstan
Subject Re: [HACKERS] Arrays of Complex Types
Date
Msg-id 46197C71.3030304@dunslane.net
Whole thread Raw
In response to Re: [HACKERS] Arrays of Complex Types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Arrays of Complex Types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
>
> 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.

good.


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

Sounds OK but I'd add something that might make it even more unlikely to
generate a name clash.

> This would also open the door to supporting
>
> CREATE TYPE foo AS ARRAY OF bar
>
> 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.
>
>
>

ISTM we should either do it all automatically or all manually. If you
want user defined names for array types then we can forget name mangling
for user defined types and do everything manually.

cheers

andrew



pgsql-patches by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] Arrays of Complex Types
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Arrays of Complex Types