2010/12/11 Florian Pflug <fgp@phlo.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
rectifiescasting everything to text.
yes, there are two no good solution now.
>
>> 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'dneed 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)
>
yes, this is probably way and I like it. But now with zero support.
a) there isn't mechanism for propagation target type from outer to
function - function have to have to know target type
b) plpgsql uses only IO cast - so values are translated to text and
back everytime
but CAST has own parser part and probably executor part too, so this
is possible and too hard.
so is possible to call: SELECT CAST(fieldvalue(myrec, 'f1', true) AS int)
yes, this task should not be hard. But who will comunicate about this with Tom?
Regards
Pavel
> 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
effortfor quite little gain...
>
> best regards,
> Florian Pflug
>
>