TODO marked as done:
o -Add support for arrays of complex types
I assume this is _not_ done, as stated below:
o Add support for arrays of domains
I will add a URL for this item:
http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php
Andrew Dunstan [EMAIL PROTECTED] writes:
Attached is my rework of David Fetter's array of composites patch. It
has all the agreed modifications and checks, except altering the name
mangling.
Applied with revisions. There are some loose ends yet:
* I didn't do anything about arrays of
Tom Lane [EMAIL PROTECTED] writes:
* I'm a bit concerned about dump order. If a user wants to create
types named foo and _foo, he can, but it will only work if he
makes _foo first --- else the derived type for foo is in the way.
Since pg_dump has no clue about that constraint, it might
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's not really the most preferable solution, I think, seeing that it
still leaves the user with the problem of having to create the types in
the right order to start with.
I'm not sure we can
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's not really the most preferable solution, I think, seeing that it
still leaves the user with the problem of having to create the types in
the right order to start with.
I'm not sure we can keep the _foo convention and avoid that.
Tom Lane wrote:
There is *tons* of legacy code that uses _foo, mainly because there was
a time when we didn't support the [] notation in a lot of places where
types can be named. There still are some places, in fact:
regression=# alter type widget[] set schema public;
ERROR: syntax error at
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Auto-rename. I'm working on a patch now, and it doesn't look like it'll
be too awful. Will post it for comments when it's working.
Ok, cool. I look forward to it.
Here's a bare-bones patch (no doc or regression tests). Seems to
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
* I'm a bit concerned about dump order. If a user wants to create
types named foo and _foo, he can, but it will only work if he
makes _foo first --- else the derived type for foo is in the way.
Since pg_dump has no clue about that
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Auto-rename. I'm working on a patch now, and it doesn't look like it'll
be too awful. Will post it for comments when it's working.
Ok, cool. I look forward to it.
Here's a bare-bones patch
Andrew Dunstan [EMAIL PROTECTED] writes:
Summarising the behaviour as I understand it:
. if you never name a type/table with a name beginning with underscore,
behaviour is as expected - type foo gets array type _foo
. if you create a type foo and then create a type _foo, the array type
for
Tom Lane wrote:
I think I like it. Certainly seems to get round the ordering problem nicely.
At least as far as the user's names are concerned. There's some
ordering dependency for the names that the array types end up with,
but we had that problem already; and AFAIK it shouldn't
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
BTW, why exactly do we need array types to have names at all?
Because typname is part of the primary key for pg_type ...
The only
user-visible way to refer to these types is always by foo[] isn't it?
I think you can use the _foo
Andrew Dunstan [EMAIL PROTECTED] writes:
There will only be an issue if you use table/type names beginning with
underscore, right? And I don't think it will matter because nobody has
been relying on that to date as we haven't had array types for those. We
should probably document that
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached version removes all the places we had NAMEDATALEN - 2
restrictions on object names. If there's no objection I will commit this
shortly, as I think it now does all the previously agreed things.
It needs some work
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm still wondering if we can get away without a catalog change on that
- e.g. could we look up an array type by looking for a pg_type entry
containing the base type's oid in the typelem field? Or would that be
too slow?
(a) too slow, (b) not
15 matches
Mail list logo
