Re: proposal: auxiliary functions for record type

Hello

I looked on your module now and I am can't to say, what is better -
both modules has little bit different target if I understand, and I
don't know if they can be mixed. There are two strategies - rich
contrib module or a few functions in core. Probably we can't to have a
too rich API for record type like regexp has - transform result to
table, to array, read values to array, to table, read tuple desc to
array, to table, ... there should be one strategy - both strategies
(based on array, based on tables) are legal. I prefer a table based
solution, because I don't need a one "unnest", but other preferences
are valid too. I dissatisfied with your design of explicit target type
via unused value. I think, so we are not a infrastructure for it now
- from my view is better to use a common type, that is text now. It's
nothing new - plpgsql use it too.

I see one well design of explicit target type based on polymorphic
types that respect a PostgreSQL fmgr practice:

We have to allow a polymorphic functions without polymorphic
parameters. These functions shoud be designed to return value in
"unknown" type format when this function has not outer information.
This information can be passed in function context. When function
context isn't null, then function has to read target type and should
to return value in target type. Who can fill a function context? It is
task for executor. And when CAST contains just function call, then we
can recheck, if function is polymorphic, and if it is, then we can set
function context to target type, and then we don't need to call a
conversion function, because polymorphic function must returns data in
correct format. So when polymorphic function is used without
polymorphic parameters and without explicit CAST, then returns
unknown.

Without described functionality we can design a not polymorphic
function, that can returns unknown type. When similar functionality
will be implemented, then this function will be changed to
polymorphic, but from user's perspective, there isn't a change.

Regards

Pavel Stehule

2010/12/11 Florian Pflug <fgp(at)phlo(dot)org>:
> On Dec11, 2010, at 17:55 , Pavel Stehule wrote:
>> It same trick, that I use in record_set_fields.
> Oh, I see. Sorry, must haven missed that when I read your blog entry.
>
>> But I don't want to
>> use it for reading of value. I don't like it. You don't need to know a
>> value, you have to know a type - NULL::type. it is just not nice :).
> Well, no, it's not the most elegant API on earth, that's for sure. But I my opinion, it isn't so bad that it rectifies casting everything to text.
>
>> I
>> though about it too, and maybe is a time for new polymorphic type
>> "anytype" - and then you don't need to write a litte bit strange
>> NULL::type
>>
>> it can be "fieldvalue(myrec, type1, false)"
> Hm, I don't think the ability to write just "type1" instead of "NULL::type1" is worth the necessary effort.
>
> If anything, I'd allow function to use anyelement as their return value *without* having any polymorphic arguments. You'd need to surround calls to such function with a CAST() expression, unless something else determines the type. In pl/pgsql, for example, one could allow the CAST() to be skipped for assignment to variables. Then, you could write
>        v_value := fieldvalue(myrec, 'f1', true)
>
> That'd at least free you from having to specify the type in some cases. But still, even this seems to be a lot of effort for quite little gain...
>
> best regards,
> Florian Pflug
>
>