Re: How hard would it be to support LIKE in return declaration of generic record function calls ?

On 05/03/2012 10:18 AM, Merlin Moncure wrote:
> On Thu, May 3, 2012 at 9:01 AM, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>> On 05/03/2012 09:43 AM, Pavel Stehule wrote:
>>> 2012/5/3 Merlin Moncure<mmoncure(at)gmail(dot)com>:
>>>> On Thu, May 3, 2012 at 7:13 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com>
>>>> wrote:
>>>>> Hello
>>>>>
>>>>>> (1 row)
>>>>>>
>>>>>> This works the same indeed, just seems to be a hack, though a cool
>>>>>> one :)
>>>> Yeah -- the syntax isn't great, but IMO it's more generally usable
>>>> than what you're proposing because it's a scalar returning function
>>>> not a table expression. Another point is that the proposed 'like'
>>>> syntax (which I still think is great, just maybe not for conversions
>>>> from json) seems wedded to record types. The hstore trick should be
>>>> able to take a foo[], set it all up and return it. How would that
>>>> work with like?
>>>>
>>>>> few years back I proposed "anytypename" type
>>>>>
>>>>> with this feature, you can has some clean and more readable call
>>>>>
>>>>> SELECT * FROM populate_record(test, ...)
>>>> that would be great IMO.
>>> I'll try propose it again - implementation should not be hard
>>>
>>>
>> You guys seem to be taking the original proposal off into the weeds. I have
>> often wanted to be able to use LIKE in type expressions, and I'd like to see
>> exactly that implemented.
> would it work for array types? can it called without using FROM?

Why would you always need FROM? I want to be able to do things like:

create type new_type as (like old_type, extra text);

i.e., anywhere we are specifying a type (e.g. as above or for a function
returnign a setof record), we should be able to import an existing one
rather than having to replicate it.

cheers

andrew