Re: Proposal: stand-alone composite types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: stand-alone composite types
Date
Msg-id 20912.1028955177@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: stand-alone composite types  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Joe Conway writes:
>> 3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
>> composite type, e.g.:

> Forgive this blunt question, but:  Why?

> Of course I can see the answer, it's convenient, but wouldn't the system
> be more consistent overall if all functions and types are declared
> explicitly?

I was wondering about that too, in particular: what name are you going
to give to the implicit type, and what if it conflicts?

The already-accepted mechanism for anonymous function-result types for
RECORD functions doesn't have that problem, because it has no need to
create a catalog entry for the anonymous type.  But I'm not sure what
to do for record types that need to be present in the catalogs.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal for psql wildcarding behavior w/schemas
Next
From: Joe Conway
Date:
Subject: Re: [GENERAL] workaround for lack of REPLACE() function