Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> Trying to do this in plpgsql is doomed to failure and heartache,
>
>> Well, the proposed functions at least allow for some more
>> flexibility in working with row types, given that you know in
>> advance which types you will be dealing with (but not necessarily
>> the precise ordering and number of the record's fields). They might
>> feel a bit kludgy because of the "anyelement" dummy argument that
>> bridges the gap between the statically typed nature of SQL and the
>> rather dynamic RECORDs, but the kludgy-ness factor is still within
>> reasonable limits I think.
>
> It sounds pretty d*mn klugy to me, and I stand by my comment that it
> isn't going to work anyway. When you try it you are going to run
> into "parameter type doesn't match that while preparing the plan"
> errors.
Ok, I must be missing something. I currently fail to see how
my proposed record_value(record, name, anyelement) returns anyelement
function differs (from the type system's point of view) from value_from_string(text, anyelement) returns anyelement
which simply casts the text value to the given type and can easily be
implemented in plpgsq.
create or replace function
value_from_string(v_value text, v_type_dummy anyelement)
returns anyelement as
$body$
declare v_result v_type_dummy%type;
begin if v_value is null then return null; end if;
v_result := v_value; return v_result;
end;
$body$ language plpgsql immutable;
-- Returns 124
select value_from_string('123', NULL::int) + 1;
-- returns {1,2,3,4}
select value_from_string('{1,2,3}', NULL::int[]) || array[4];
best regards,
Florian Pflug