[BUGS] BUG #3413: character string or multibyte character to "char"

[Toru SHIMOGAKI]

The following bug has been logged online:

Bug reference:  3413
Logged by:  Toru SHIMOGAKI
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system:   Red Hat Enterprise Linux AS4
Description:character string or multibyte character to "char"
Details: 

When a character string or a multibyte character is inserted to "char"
column, no error occurs. Is this a bug? Should it be checked as "not single
character" in charin(), charrecv() and charout()? 

Anyway, I can't find any spec descriptions in the following document;
  http://www.postgresql.org/docs/8.2/static/datatype-character.html

Best regards,




postgres=# select version();
  version

---
 PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-3)
(1 row)

postgres=# create table test(flag "char");
CREATE TABLE
postgres=# \d test
 Table "public.test"
 Column |  Type  | Modifiers
++---
 flag   | "char" |

postgres=# insert into test values('a');
INSERT 0 1
postgres=# insert into test values('bb');
INSERT 0 1
postgres=# insert into test values('e');
INSERT 0 1
postgres=# insert into test values('あ');
INSERT 0 1
postgres=# select * from test;
 flag
--
 a
 b
 e

(4 rows)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] BUG #3413: character string or multibyte character to "char"

[Toru SHIMOGAKI]

This is a sample patch for charin() and charrecv(). I'm not sure for charout();
it can return non-ASCII character...


Toru SHIMOGAKI wrote:
> The following bug has been logged online:
> 
> Bug reference:  3413
> Logged by:  Toru SHIMOGAKI
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system:   Red Hat Enterprise Linux AS4
> Description:character string or multibyte character to "char"
> Details: 
> 
> When a character string or a multibyte character is inserted to "char"
> column, no error occurs. Is this a bug? Should it be checked as "not single
> character" in charin(), charrecv() and charout()? 
> 
> Anyway, I can't find any spec descriptions in the following document;
>   http://www.postgresql.org/docs/8.2/static/datatype-character.html
> 
> Best regards,
> 
> 
> 
> 
> postgres=# select version();
>   version
> 
> ---
>  PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
> 20060404 (Red Hat 3.4.6-3)
> (1 row)
> 
> postgres=# create table test(flag "char");
> CREATE TABLE
> postgres=# \d test
>  Table "public.test"
>  Column |  Type  | Modifiers
> ++---
>  flag   | "char" |
> 
> postgres=# insert into test values('a');
> INSERT 0 1
> postgres=# insert into test values('bb');
> INSERT 0 1
> postgres=# insert into test values('e');
> INSERT 0 1
> postgres=# insert into test values('あ');
> INSERT 0 1
> postgres=# select * from test;
>  flag
> --
>  a
>  b
>  e
> 
> (4 rows)
> 
> ---(end of broadcast)---
> TIP 7: You can help support the PostgreSQL project by donating at
> 
> http://www.postgresql.org/about/donate
> 
> 

-- 
Toru SHIMOGAKI<[EMAIL PROTECTED]>
NTT Open Source Software Center
Index: src/backend/utils/adt/char.c
===
--- src/backend/utils/adt/char.c(revision 1156)
+++ src/backend/utils/adt/char.c(working copy)
@@ -34,6 +34,11 @@
 {
char   *ch = PG_GETARG_CSTRING(0);
 
+   if (ch[0] != '\0' && ch[1] != '\0')
+   ereport(ERROR,
+   (errcode(ERRCODE_STRING_DATA_RIGHT_TRUNCATION),
+errmsg("value too long for type \"char\"")));
+
PG_RETURN_CHAR(ch[0]);
 }
 
@@ -67,6 +72,11 @@
 {
StringInfo  buf = (StringInfo) PG_GETARG_POINTER(0);
 
+   if (buf->len > 1)
+   ereport(ERROR,
+   (errcode(ERRCODE_STRING_DATA_RIGHT_TRUNCATION),
+errmsg("value too long for type \"char\"")));
+
PG_RETURN_CHAR(pq_getmsgbyte(buf));
 }
 

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [BUGS] REVOKE CREATE does not work on default tablespace

[Zdenek Kotala]

Tom Lane wrote:

Zdenek Kotala <[EMAIL PROTECTED]> writes:

Tom Lane wrote:

It's presumed that the right to create tables within a database entails
the right to create them someplace; hence no permissions check is made
on the database's default tablespace.  Without that, not only does plain
CREATE TABLE fail (including CREATE TEMP TABLE), but any query complex
enough to require a temporary file would fail as well.  So you'd pretty
much have to grant rights on the tablespace to every user of the database
anyway.


If only temporary objects are problem I think better solution is to create 
pg_temp tablespace which will be used as default for temporary data


Why are you so eager to make CREATE TABLE fail?  (If you really want to
do that there are other ways, for instance revoking create privilege
within the DB.)


I expect it if I revoke rights to do it. This behavior is non documented (I did 
not find it in documentation) and it is also exception of ACL behavior. If you 
forgot to revoke create rights on public schema normal user is able to inject 
own table and override another in different schema during search_path evaluation 
(see for example security definer issue). I also expect when I use tablespace 
name in command which is same as default tablespace I get same result.


I still does not see any benefit from user side why postgres has this exception. 
It is confusing and it should generate potential security risk.


By the way, there is also strange behavior when for example you want to create 
table with primary key. Index is stored in default tablespace instead of same as 
table has.



Once you've created a database with a given tablespace as default, the
only way to make it stop using the tablespace is to drop the whole DB;
there are no half measures because you can't move the system catalogs
(particularly not pg_class).  So I'm not seeing the point of enforcing
tablespace usage against users of the database rather than at the time
of DB creation.


I don't want to stop usage the default tablespace, I'm only want to stop user 
create there new tables.



Zdenek

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [BUGS] BUG #3413: character string or multibyte character to "char"

[Tom Lane]

"Toru SHIMOGAKI" <[EMAIL PROTECTED]> writes:
> When a character string or a multibyte character is inserted to "char"
> column, no error occurs. Is this a bug?

That's the historical behavior of the datatype, and given that it's
been like that since Berkeley days, changing it seems ill-advised.
If you want a column that behaves sanely for multibyte data, use
char(1).

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [BUGS] REVOKE CREATE does not work on default tablespace

[Tom Lane]

Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I still does not see any benefit from user side why postgres has this
> exception.  It is confusing and it should generate potential security
> risk.

"Security risk"?  Now you're just making things up.

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] PL/pgSQL RAISE EXCEPTION ignores escape characters even with new E'' string syntax

[Donald Fraser]

PostgreSQL 8.1.9

According to the release notes, PostgreSQL still handles escape characters in 
strings as it has in the past, yet PL/pgSQL functions that use escape 
characters within the string definition for RAISE EXCEPTION are ignored, unless 
the function is created using the old style quote definition (not $$).


Observe the following four test functions using PL/pgSQL.

CREATE OR REPLACE FUNCTION test_func_exception() RETURNS void AS '
BEGIN 
 RAISE EXCEPTION \'This is an error message.\nThis is a message on a new 
line\';
 RETURN;
END ' 
LANGUAGE 'plpgsql' VOLATILE SECURITY DEFINER;


CREATE OR REPLACE FUNCTION test_func_exception2() RETURNS void AS
$BODY$
BEGIN 
 RAISE EXCEPTION 'This is an error message.\nThis is a message on a new 
line';
 RETURN;
END $BODY$
LANGUAGE 'plpgsql' VOLATILE SECURITY DEFINER;

CREATE OR REPLACE FUNCTION test_func_exception3() RETURNS void AS
$BODY$
BEGIN 
 RAISE EXCEPTION E'This is an error message.\nThis is a message on a new 
line';
 RETURN;
END $BODY$
LANGUAGE 'plpgsql' VOLATILE SECURITY DEFINER;


CREATE OR REPLACE FUNCTION test_func_exception4() RETURNS void AS
$BODY$
DECLARE 
 smessage text;
BEGIN 
 smessage := 'This is an error message.\nThis is a message on a new line';
 RAISE EXCEPTION '%',smessage;
 RETURN;
END $BODY$
LANGUAGE 'plpgsql' VOLATILE SECURITY DEFINER;

Out put from the four test functions are as follows:

1)
select test_func_exception();
ERROR:  This is an error message.
This is a message on a new line

2)
select test_func_exception2();
ERROR:  This is an error message.nThis is a message on a new line

3)
select test_func_exception3();
ERROR:  This is an error message.nThis is a message on a new line

4)
select test_func_exception4();
ERROR:  This is an error message.
This is a message on a new line

You will note that even using the new E'' string format syntax for the RAISE 
EXCEPTION appears to be broken (test_func_exception3()).
I can't find anything in the documentation that suggests this should be the 
observed behaviour.

Regards
Donald Fraser

Re: [BUGS] PL/pgSQL RAISE EXCEPTION ignores escape characters even with new E'' string syntax

[Tom Lane]

"Donald Fraser" <[EMAIL PROTECTED]> writes:
> According to the release notes, PostgreSQL still handles escape =
> characters in strings as it has in the past, yet PL/pgSQL functions that =
> use escape characters within the string definition for RAISE EXCEPTION =
> are ignored, unless the function is created using the old style quote =
> definition (not $$).

I think you are confused.  plpgsql has never interpreted \n as a return;
if that's happening, it's in the string literal parser that eats the
function body string.

Looking at the source code, it appears that plpgsql's scanner treats
E'' and '' strings the same, which we probably should change sometime
(though the risks for breaking existing functions, perhaps with
unpleasant security implications, seem high).  But the examples you
give address what happens when the string is read by CREATE FUNCTION,
not what plpgsql does when running the function.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[BUGS] BUG #3414: client-only install fails due to parse.h file not found

[Geoff Taylor]

The following bug has been logged online:

Bug reference:  3414
Logged by:  Geoff Taylor
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.9
Operating system:   Redhat Linux
Description:client-only install fails due to parse.h file not found
Details: 

I tried the client-only install for the 8.1.9 tarball.

I downloaded the tarball, unzipped, untarred.
Then I ran ./configure with no options.

On the first step:
 gmake -C src/bin install

make couldn't find parse.h. (see log below)

Later I got it to compile OK by copying:

cp src/backend/parser/parse.h src/include/parser/

Log snippet for the compile failure:

[EMAIL PROTECTED] postgresql-8.1.9]# gmake -C src/bin install


make[2]: Entering directory `/tmp/postgresql-8.1.9/src/backend/parser'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -W endif-labels -fno-strict-aliasing -I.
-I../../../src/include -D_GNU_SOURCE   -c -o keywords. o keywords.c
keywords.c:21:26: parser/parse.h: No such file or directory
keywords.c:33: error: `ABORT_P' undeclared here (not in a function)
keywords.c:33: error: initializer element is not constant

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[BUGS] BUG #3415: plperl spi_exec_prepared variable undef value confusion

[Matt]

The following bug has been logged online:

Bug reference:  3415
Logged by:  Matt
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system:   ubuntu 7.04, gentoo 2007.0
Description:plperl spi_exec_prepared variable undef value confusion
Details: 

When inserting a null timestamp from a variable, I encounter the following:
ERROR:  error from Perl function: invalid input syntax for type timestamp:
""

To replicate the problem
1. Prepare a statement: spi_prepare(...),
2. Set a variable: my $var = ...,
3. Re-set the variable's value: $var = undef,
4. Execute the prepared statement: spi_exec_prepared(...)

Matt Taylor

The following code should recreate the problem:


create table bug_demo_table ( x timestamp );

create function bug_demo() returns integer as $$

  use strict;
  use Data::Dumper;

  # prepare the statement
  my $sql = 'insert into bug_demo_table ( x ) ';
  $sql .= 'values ( $1 );' ;
  my $sth = spi_prepare( $sql, 'timestamp' );

  # first set the variable to some appropriate value
  my $var = '2007-01-01 01:01:01.000';
  elog(NOTICE, "\n". Dumper($var). "\n");

  # set the variable to undef
  $var = undef; # fails
  elog(NOTICE, "\n". Dumper($var). "\n");

  # re-initialize the variable and set it to undef
  # uncomment this line to prevent the error
  #my $var = undef;  # works

  spi_exec_prepared( $sth, $var ); # fails

  return 1;

$$ LANGUAGE 'plperlu';

select bug_demo();

select * from bug_demo_table;

drop table bug_demo_table cascade;
drop function bug_demo() cascade;

---(end of broadcast)---
TIP 6: explain analyze is your friend