Re: [GENERAL] string_to_array with empty input - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [GENERAL] string_to_array with empty input
Date
Msg-id 603c8f070904020450x20060643ie49a36f577cbc3a3@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] string_to_array with empty input  (Tino Wildenhain <tino@living-examples.com>)
List pgsql-hackers
>> I'm speaking primarily of functions as first-class objects, though
>> closures would be nice too.   But consider an operation like
>>
>> UPDATE rel SET col1 = MAP ( f OVER col2 )
>>
>> We need to be able to determine whether this is well-typed, just as we
>> do now for any other SQL query.  Specifically, we need to check that f
>> is a one argument function whose argument type is that of col2 and
>> whose return type is that of col1.  My understanding is that right now
>> types are represented as 32-bit OIDs.  I think they'd need to be some
>> sort of more complex structure in order to handle cases like this.
>
> Would above query not be written as
>
> UPDATE rel SET col1 = f(col2);
>
> anyway or am I missing something?

Ah, sorry, I mis-stated it slightly.  I was imagining that col2 and
col1 where arrays, and f was a function between the base types, not
the array types.

> imho, having generic tuple tables as we have in INSERT INTO (...)
> VALUES (...),(...),(...)
>
> to be useable in all places like a real table would be helpful in
> many cases.
>
> But this might be completely unrelated :)

Probably.  :-)

...Robert


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [COMMITTERS] pgsql: Explicitly bind gettext to the correct encoding on Windows.
Next
From: Robert Haas
Date:
Subject: Re: Bug of ALTER TABLE DROP CONSTRAINT