Функция PostgreSQL с произвольным типом возвращаемых данных

Вот основная таблица с данными:

CREATE TABLE my_report
(
  id               serial                      NOT NULL primary key,
  report_timestamp timestamp without time zone NOT NULL,
  value_id         integer                     NOT NULL,
  text_value       character varying(255),
  numeric_value    double precision,
  bool_value       boolean,
  dt_value         timestamp with time zone,
  CONSTRAINT my_report_fkey_valdef FOREIGN KEY (value_id)
      REFERENCES public.my_value_defs (value_id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE RESTRICT
);

Он содержит несколько столбцов для каждого значения, поскольку значения могут иметь разные типы данных.

Какой столбец будет выбран, зависит от столбца data_type второй таблицы, связанной с внешним ключом value_id:

CREATE TABLE my_value_defs
(
  value_id     serial                NOT NULL primary key,
  value_name   character varying(50) NOT NULL,
  data_type    integer               NOT NULL,
  CONSTRAINT my_value_defs_pkey PRIMARY KEY (value_id),
  CONSTRAINT my_value_defs_value_name_key UNIQUE (value_name)
);

Теперь я пытаюсь сократить огромный SQL-запрос, создав функцию, которая может возвращать либо text_value, либо numeric_value, либо bool_value, либо dt_value, но обнаружил, что я должен явно определить возвращаемый тип данных:

CREATE OR REPLACE FUNCTION public.rep_dta_val(
    val_id integer,
    dt timestamp with time zone,
    timeout integer)
  RETURNS timestamp with time zone AS -- ********** HERE **********
$BODY$SELECT
   r.dt_value
FROM
   my_report r
WHERE
   r.value_id = val_id
   AND r.report_timestamp BETWEEN
      dt - make_interval(secs := timeout)
      AND dt
ORDER BY
   r.report_timestamp desc
LIMIT 1;$BODY$
  LANGUAGE sql VOLATILE
  COST 100;

Эта функция еще не завершена, поэтому, пожалуйста, не жалуйтесь на нее здесь.

Я не люблю все переводить в текст. Типы данных следует сохранить.

Когда невозможно создать функцию с переменным типом выходных данных, я должен сгенерировать в своем приложении полный SQL-запрос полной длины следующим образом:

SELECT
(SELECT r.text_value    as acc_right     FROM my_report r WHERE r.value_id =  3 AND r.report_timestamp BETWEEN now() - INTERVAL '60 seconds' AND now() ORDER BY r.report_timestamp desc LIMIT 1),
(SELECT r.numeric_value as h_angle       FROM my_report r WHERE r.value_id =  4 AND r.report_timestamp BETWEEN now() - INTERVAL '60 seconds' AND now() ORDER BY r.report_timestamp desc LIMIT 1),
(SELECT r.text_value    as vol_flow      FROM my_report r WHERE r.value_id = 25 AND r.report_timestamp BETWEEN now() - INTERVAL '60 seconds' AND now() ORDER BY r.report_timestamp desc LIMIT 1),
(SELECT r.numeric_value as draft_mid     FROM my_report r WHERE r.value_id = 57 AND r.report_timestamp BETWEEN now() - INTERVAL '60 seconds' AND now() ORDER BY r.report_timestamp desc LIMIT 1),
(SELECT r.dt_value      as eta_timestamp FROM my_report r WHERE r.value_id = 58 AND r.report_timestamp BETWEEN now() - INTERVAL '60 seconds' AND now() ORDER BY r.report_timestamp desc LIMIT 1);

Вышеупомянутый запрос делает именно то, что мне нужно, но он слишком длинный, поэтому я создал несколько функций, по одной для каждого типа данных, и использую их следующим образом:

SELECT
rep_txt_val( 3, now(), 60) as acc_right,
rep_num_val( 4, now(), 60) as h_angle,
rep_txt_val(25, now(), 60) as vol_flow,
rep_num_val(57, now(), 60) as draft_mid,
rep_dta_val(58, now(), 60) as eta_timestamp;

Теперь хотелось бы иметь универсальную функцию для всех типов данных.

P.S. Зачем использовать EAV?

Потому что раньше это была обычная таблица, и ЭТО было кошмаром, потому что время от времени нужно было автоматически создавать столбцы. Иногда обычный пользователь не имеет прав на выполнение команд DDL.

У меня есть полностью динамически настраиваемое программное обеспечение, и количество значений, которые необходимо сохранить в таблице, зависит от файла конфигурации этого программного обеспечения. Я выбрал эту модель, чтобы упростить обслуживание базы данных и передачу данных между системами.

Кроме того, я мог бы сказать, что различные значения должны сохраняться через определенные промежутки времени.

Так что я не откажусь от EAV, потому что он уже работает более эффективно, чем прежняя обычная таблица.

Нет необходимости представлять эту вертикальную структуру в виде горизонтальных строк данных, за исключением экспорта для устаревших систем. И это как раз тема моего вопроса.