Andrew Dunstan <[EMAIL PROTECTED]> 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'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.
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
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.
regards, tom lane
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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
