From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | PALAYRET Jacques <jacques(dot)palayret(at)meteo(dot)fr> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: PostgreSQL include directive in plpgsql language PL/pgSQL |
Date: | 2025-09-08 16:31:52 |
Message-ID: | CAHyXU0wz3i=xgSKzMfoC_57Ya3m2FO=Y=rzmLVcWEJF=hWv4cw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Sep 8, 2025 at 3:37 AM PALAYRET Jacques <jacques(dot)palayret(at)meteo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Klaus Darilion | 2025-09-08 16:37:52 | RE: Fast switchover |
Previous Message | Ron Johnson | 2025-09-08 16:10:18 | Re: Fast switchover |