From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Matthias Apitz <guru(at)unixarea(dot)de>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ESQL/C no indicator variables ./. error -213 |
Date: | 2020-06-18 14:27:26 |
Message-ID: | 2ec31705b9c4a5e8ff8627a9f5a4edb099fd7edd.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2020-06-17 at 19:02 +0200, Matthias Apitz wrote:
> We encountered that if our ESQL/C written servers see on SELECT or FETCH
> in a row a NULL value, it will raise correctly the error -213 as written
> and explained in https://www.postgresql.org/docs/11/ecpg-variables.html#ECPG-INDICATORS
> We catch this error -213 and deal with in.
>
> What we did not knew and discovered today is something very fatal: In
> such a situation on a FETCH of a row of some 55 columns, the transfer of
> the column elements into their hostvariables stops on first NULL value,
> as here to be seen in the log:
>
> [29217] [17.06.2020 15:49:16:499]: ecpg_execute on line 69: query: select * from acq_ffleit where bnr = $1 ; with 1 parameter(s) on connection sisis
> [29217] [17.06.2020 15:49:16:500]: ecpg_execute on line 69: using PQexecParams
> [29217] [17.06.2020 15:49:16:500]: ecpg_free_params on line 69: parameter 1 = 742
> [29217] [17.06.2020 15:49:16:500]: ecpg_process_output on line 69: correctly got 1 tuples with 55 fields
> [29217] [17.06.2020 15:49:16:500]: ecpg_get_data on line 69: RESULT: 742 offset: 752; array: no
> ...
> [29217] [17.06.2020 15:49:16:500]: ecpg_get_data on line 69: RESULT: 49 offset: 752; array: no
> [29217] [17.06.2020 15:49:16:500]: ecpg_get_data on line 69: RESULT: offset: 752; array: no
> [29217] [17.06.2020 15:49:16:500]: raising sqlcode -213 on line 69: null value without indicator on line 69
>
> In the above examples the transfer stopped after 47 RESULTs; the
> hostvariables after this have been untouched in our program, i.e. only
> part of the row has been read.
>
> One could say, "so what, you have error -213 and you deserve it". But at
> least this behaviour should be documented clearly in the above mentioned page.
>
> I would expect, that NULL values would not be transfered in such case
> but all other hostvariables yes, i.e. for me this is perhaps a bug in the
> ESQL/C implementation.
I think that is as expected.
The documentation says:
To be able to pass null values to the database or retrieve null values from the database,
you need to append a second host variable specification to each host variable that contains data.
This second host variable is called the *indicator* [...]
Failure to do that causes an error (which you catch).
If a statement causes an error, you cannot rely on the state of any host valiable
that gets set by that statement.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-06-18 14:38:30 | Re: Conflict with recovery on PG version 11.6 |
Previous Message | Winfield, Steven | 2020-06-18 14:26:04 | Re: Parallel safety of contrib extensions |