2006-11-27 16:16 >>> Hi, Bart, Bart Degryse wrote: > I suppose your statement > test=3D# select '\x'||'65'; > is done on some command line interface. I don't have that. I can only > use some client program. All versions of PostgreSQL I know are shipped with "psql" as command line interface. (It's a client program, actually. :-) > I'm using EMS SQL Manager 2007 and pgAdmin III 1.3 > None of them accepts your statement. I just tried with pgAdmin III 1.4.3, and it worked fine. > When I try to do the same for a range of hex values ( FOR i IN 101..101 > LOOP charset :=3D charset || '\x' || to_hex(i); ) it is not longer a > bunch of hex values that get stored but a series of varchars. The problem is that the \x escaping is done in the parser, so in your first function, the query engine actually sees "charset :=3D charset || 'e';" In the second function, the '\x' string is parsed as is, and converted to the String 'x' instead of being rejected as broken \x sequence, I think for compatibility reasons. Then, the engine sees: "charset :=3D charset || 'x' || to_hex(i);" Maybe you can change it to (ASCII version): "charset :=3D charset || chr(i);" or (256-bit version): "charset :=3D charset || decode(to_hex(i),'hex'); HTH, Markus --=20 Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org --=__Part4C686F0F.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML

Hi Markus,

I should have said "The ICT department doesn't give me access to the = psql command line interface".

Thanks for explaining what goes wrong. I now understand the problem. = It doesn't solve it though.

I haven't tried your first suggestion since ASCII won't be = good enough. I also need to be able to do something like

charset :=3D charset || '\xC2\xA9';

but then in the dynamic form like

charset :=3D charset || '\xC2\x' || to_hex(i)';
So I = thought your second suggestion might be of help.

I get an error though:

ERROR: operator does not exist: character varying || bytea
HI= NT: No operator matches the given name and argument type(s). You may = need to add explicit type casts.
CONTEXT: SQL statement "SELECT&nb= sp; $1 || decode(to_hex( $2 ), 'hex')"

>>> Markus Schaber <schabi@logix-tt.com> 2006-11-27= 16:16 >>>

Hi, Bart,

Bart Degryse wrote:

&= gt; I suppose your statement
> test=3D# select '\x'||'65';
> = is done on some command line interface. I don't have that. I can only
&g= t; use some client program.

All versions of PostgreSQL I know are = shipped with "psql" as command
line interface. (It's a client program, = actually. :-)

> I'm using EMS SQL Manager 2007 and pgAdmin III = 1.3
> None of them accepts your statement.

I just tried with = pgAdmin III 1.4.3, and it worked fine.

> When I try to do the = same for a range of hex values ( FOR i IN 101..101
> LOOP = charset :=3D charset || '\x' || to_hex(i); ) it is not = longer a
> bunch of hex values that get stored but a series of = varchars.

The problem is that the \x escaping is done in the = parser, so in your
first function, the query engine actually sees
"ch= arset :=3D charset || 'e';"

In the second function, the '\x' string = is parsed as is, and converted
to the String 'x' instead of being = rejected as broken \x sequence, I
think for compatibility reasons. = Then, the engine sees:
"charset :=3D charset || 'x' || to_hex(i);"

Maybe you can change it to (ASCII version):
"charset :=3D charset = || chr(i);"
or (256-bit version):
"charset :=3D charset || decode(to_= hex(i),'hex');

HTH,
Markus
--
Markus Schaber | = Logical Tracking&Tracing International AG
Dipl. Inf. &nbs= p; | Software Development GIS

Fight against software patents = in Europe! www.ffii.org
www.nosoftwarepatents.org
=

--=__Part4C686F0F.1__=--