Re: PostgreSQL include directive in plpgsql language PL/pgSQL
| От | Merlin Moncure |
|---|---|
| Тема | Re: PostgreSQL include directive in plpgsql language PL/pgSQL |
| Дата | |
| Msg-id | CAHyXU0wz3i=xgSKzMfoC_57Ya3m2FO=Y=rzmLVcWEJF=hWv4cw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL include directive in plpgsql language PL/pgSQL (PALAYRET Jacques <jacques.palayret@meteo.fr>) |
| Список | pgsql-general |
On Mon, Sep 8, 2025 at 3:37 AM PALAYRET Jacques <jacques.palayret@meteo.fr> wrote:
Hello,Thanks for your response.# Currently, I have a function text and a function array with the same body but a distinct type return.
-> Example with the array of text function :
SELECT public.calfxi3s_all_elements_text_array(12345678, '2025-01-01 00:00') ;
calfxi3s_all_elements_text_array
-------------------------------------------------------------------------
{3.2,sonic,"Capteur Vent ultrasonique compact Brand xxx",2,-0.123,0.321}
That gives some parameters : the value of the wind strength (3.2), the kind of sensor (sonic), the model (Capteur ...), the environmment (2), two coefficients (-0.123,0.321)
Right. I guess your issue might be in calfxi3s_all_elements_text_array().
Is there any specific reason why this must return an array vs a composite type? I guess the basic issue here is trying to abuse the array type when a composite type might have many advantages here.
CREATE TYPE sensor_measurement_t AS
(
wind_strength numeric,
sensor text,
model text,
environment int,
coefficient1 numeric,
coefficient2 numeric
);
CREATE FUNCTION calfxi3s_all_elements(...) RETURNS sensor_measurement_t AS ..
SELECT * FROM calfxi3s_all_elements(...);
SELECT model FROM calfxi3s_all_elements(...);
melin
В списке pgsql-general по дате отправления: