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

[Florian G. Pflug]

Tom Lane wrote:

"Florian G. Pflug" <f...@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.

into "parameter type doesn't match that while preparing the plan"
errors.

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

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

smime.p7s
Description: S/MIME Cryptographic Signature