Re: Inspection of row types in pl/pgsql and pl/sql

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