Hannu Krosing wrote:
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Hannu Krosing writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote:
>
> Tom Lane wrote:
> > Hannu Krosing writes:
> >
> >> So SPI interface should also be fixed, either from perl side, or maybe
> >> from inside SPI ?
> >>
> >
> > SPI has every right to assume that data it's given is already in the
>
Tom Lane wrote:
Hannu Krosing writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
Yeah, looks like we missed a few spot
Hannu Krosing writes:
> So SPI interface should also be fixed, either from perl side, or maybe
> from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Sat, 2010-01-02 at 20:51 -0500, Andrew Dunstan wrote:
>
> Andrew Dunstan wrote:
> >
> > I think the plperl glue code should check returned strings using
> > pg_verifymbstr().
> >
> >
>
> Please test this patch. I think we'd probably want to trap the encoding
> error and issue a customised
Andrew Dunstan writes:
> How about we just change the hint so it also refers to the possibility
> that the data comes from a PL? That would save lots of trouble.
Maybe just lose the hint altogether. It's not adding that much,
and I seem to recall that there have already been complaints about
ot
Tom Lane wrote:
Andrew Dunstan writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding "UTF8": 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
On sön, 2010-01-03 at 18:40 -0500, Andrew Dunstan wrote:
> Incidentally, I guess we need to look at plpython and pltcl for
> similar issues.
I confirm that the same issue exists in plpython.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
Tom Lane wrote:
Andrew Dunstan writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding "UTF8": 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
Andrew Dunstan writes:
> There are two issues with this patch. First, how far if at all should it
> be backpatched? All the way, or 8.3, where we tightened the encoding
> rules, or not at all?
Forgot to mention --- I'm not in favor of backpatching. First because
tightening encoding verificatio
Andrew Dunstan writes:
> andrew=# select 'a' || invalid_utf_seq() || 'b';
> ERROR: invalid byte sequence for encoding "UTF8": 0xd0
> HINT: This error can also happen if the byte sequence does not
> match the encoding expected by the server, which is controlled by
> "client_en
David E. Wheeler wrote:
Second, It produces errors like this:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding "UTF8": 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is con
On Jan 3, 2010, at 11:54 AM, Andrew Dunstan wrote:
> There are two issues with this patch. First, how far if at all should it be
> backpatched? All the way, or 8.3, where we tightened the encoding rules, or
> not at all?
8.3 seems reasonable.
> Second, It produces errors like this:
>
> andr
I wrote:
I think the attached patch plugs the direct SPI holes as well.
There are two issues with this patch. First, how far if at all should it
be backpatched? All the way, or 8.3, where we tightened the encoding
rules, or not at all?
Second, It produces errors like this:
andrew=# s
Tom Lane wrote:
Andrew Dunstan writes:
One thing that I am pondering is: how does SPI handle things if the
client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
Andrew Dunstan writes:
> One thing that I am pondering is: how does SPI handle things if the
> client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
regards, tom lane
-
Andrew Dunstan wrote:
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the
encoding error and issue a customised error message, but this plugs
all the holes I can see w
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the encoding
error and issue a customised error message, but this plugs all the holes
I can see with the possible exceptio
Hannu Krosing wrote:
[plperl can return data that is not valid in the server encoding and it
is not caught]
This results in a table, which has invalid utf sequence in it and
consequently does not pass dump/load
What would be the best place to fix this ?
Should there be checks in all text
It is possible to get an invalid byte sequence into a text field via pl,
in this case pl/perl :
---8<--8<--8<--8<--8<--8<---
CREATE TABLE utf_test
(
id serial PRIMARY KEY,
data character varying
);
CREATE OR REPLACE FUNCTION invalid_utf_seq()
RETURNS character varying A
20 matches
Mail list logo
