From: Merlin Moncure on
On Tue, Jan 12, 2010 at 9:00 AM, Andrew Dunstan <andrew(a)dunslane.net> wrote:
> What is the point of this discussion? We're not going to remove the facility
> for composite types, regardless of whether or not some people regard them as
> unnecessary. And "a name that better suits the task" is not to be sneered at
> anyway.

nobody is arguing to remove the create type syntax. I suppose in
hindsight more thought might have been given to the overlap w/create
table. Also you have to admit that having both 'create type' and
'create type as' which do completely different things is pretty
awkward. in addition, we have 'create table' which gives us three
different methods of creating types, each with their own nuance and
advantages. please understand, I'm not griping: the postgresql type
system is wonderful...there's nothing else quite like it out there.

The questions I am posing are this:
*) should 'create type as' get an 'alter'? ( I think most would think so)
*) if so, how do you distinguish between the composite and non
composite version? How would this command look?
*) should we be able to define check constraints on composite types
(presumably, enforced on a cast)?
*) should 'create type as' should be walled off with 'create table'
handling most cases of type creation? (previously would have said yes,
but with typed table enhancement, probably not)

merlin




merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on
On tis, 2010-01-12 at 09:54 -0500, Merlin Moncure wrote:
> *) should 'create type as' get an 'alter'? ( I think most would think so)

Working on that right now ...

> *) if so, how do you distinguish between the composite and non
> composite version? How would this command look?

I'm only dealing with the composite types right now, and the syntax is
ALTER TYPE name ADD/DROP ATTRIBUTE name, per SQL standard.

> *) should we be able to define check constraints on composite types
> (presumably, enforced on a cast)?

That could be an interesting feature addition. It'd basically be the
composite-type version of domains.

> *) should 'create type as' should be walled off with 'create table'
> handling most cases of type creation? (previously would have said yes,
> but with typed table enhancement, probably not)

This might be a matter of taste, but also note that these interfaces are
prescribed by the SQL standard, so if you have them, they should do the
things the spec says.



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Joe Conway on
On 01/12/2010 06:43 AM, Andrew Chernow wrote:
>>
>> What is the point of this discussion? We're not going to remove the
>> facility for composite types, regardless of whether or not some people
>> regard them as unnecessary. And "a name that better suits the task" is
>> not to be sneered at anyway.
>>
>
> I never asked for anything to be removed nor do I sneer :) Honestly, I
> was only trying to understand why it existed.

It exists because once upon a time when SRFs were first created, and you
were using a function returning SETOF RECORD, you would either have to
enumerate every column definition in your query, or create a "dummy"
table that had the right columns/types to match your return tuple.

That solution was generally viewed as grotty -- the former is a lot of
typing and clutter, and the latter creates a table with the only purpose
being to get the needed composite type created. Therefore we added the
ability to skip the table creation and just produce the needed composite
type.

HTH

Joe