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:
> 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
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
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 crea
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
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
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 abo
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
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Then I think we need to work out a way to make pg_dump smart enough to
> dump things in the right order.
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
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Then I think we need to work out a way to make pg_dump smart enough to
dump things in the right order.
That's not really the most preferable solution, I think, seeing that it
still leaves the user with the problem of having t
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:
>> 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 av
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 ke
"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,
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 array
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:
> 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 yet, but I'll go over
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 u
18 matches
Mail list logo
