Базовые типы PostgreSQL (скалярный тип)

У меня есть пример использования, когда пользовательский базовый тип в базе данных PostgreSQL был бы очень полезен для работы с нелинейными данными. Примеры этого включают определение использования функции ввода и вывода для функции C. В моем случае я бы предпочел просто определить функции ввода и вывода с помощью SQL, а затем использовать «LIKE», чтобы наследовать все остальное от двойной точности. Кто-нибудь сделал это? это вообще возможно?

Возможный пример:

-- sample linear to logrithmic functions
CREATE FUNCTION to_linear(anyelement) RETURNS double precision
    LANGUAGE SQL
AS
$$
SELECT CASE WHEN $1 > 0 THEN 30 / log($1::double precision) ELSE 0 END
$$;

create function to_log(anyelement) returns double precision
    language sql
as $$
select 10^($1::double precision/30.0);
$$;

-- create the base type
create type mylogdata
(

    INPUT = to_linear,
    OUTPUT = to_log,
    LIKE = double precision
) ;

-- sample use in a table definition 
CREATE TABLE test_table(
    mydata mylogdata
);

Что мне действительно нужно, так это «sudo» или «частичный» базовый тип, позволяющий выполнять простые преобразования ввода-вывода, позволяя существующим функциям (сумма, среднее и т. д.) работать с унаследованным типом (в в этом случае двойная точность); в основном избегая написания/перезаписи функций на C.

Мысли? Идеи? Комментарии? Невозможно? :)

Большое спасибо!


Кстати, если бы мы пошли по маршруту «C», я думаю, что могла бы быть возможность создать более общий логарифмический скаляр/базовый тип, такой как Char, Varchar или число произвольной точности, которое могло бы позволить для динамическое объявление логарифмической базы и шкалы нелинейных данных.

Нечто подобное может принести большую пользу научному сообществу и тем из нас, кто имеет дело с данными на основе «волн», такими как звук, вибрация, землетрясения, свет, радиация и т. д. Вот примерное определение базы:

Логарифмический (база, масштаб)

-- Below my idea for use in a table definition 
-- Obviously the IN/OUT functions would have to be modified to use the base and scaling
-- as defined (  most likely in C ??  )

CREATE TABLE test_table
(
    mydata logarithmic(10, 30)
);

Если кто-то заинтересован в партнерстве в создании чего-то подобного, дайте мне знать.


person warchitect    schedule 20.02.2020    source источник


Ответы (1)


Если вы хотите написать тип данных с новыми функциями ввода и вывода, вы должны написать это на C. Без сомнения, вы можете повторно использовать множество функций из double precision.

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

Если вы создаете класс операторов для своих новых операторов, вы также можете использовать их с индексами.

person Laurenz Albe    schedule 21.02.2020
comment
Интересная идея ... так что вы думаете о создании нового оператора, такого как +++, чтобы добавить. Итак, как бы вы реализовали такой агрегат, как logsum()? Кроме того, одна из основных идей для нового типа заключается в том, чтобы позволить инструментам бизнес-аналитики естественным образом взаимодействовать с лежащими в основе логарифмическими данными, чтобы сумма или среднее значение были логарифмической суммой или средним значением. - person warchitect; 21.02.2020
comment
Если вам нужны нормальные операторы, моя идея вам не поможет. Однако реализовать агрегаты в SQL несложно. - person Laurenz Albe; 21.02.2020
comment
- Можешь взглянуть на это - почему это не работает? что я пропустил? :) sqlfiddle.com/#!17/a3e4b/1 - person warchitect; 24.02.2020
comment
SFUNC должен изменить состояние с помощью нового ввода, но ваш log_add использует только $1 (первый аргумент). Это выглядит неправильно. - person Laurenz Albe; 25.02.2020