dbTalk Databases Forums  

[BUGS] BUG #2390: check constraint

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss [BUGS] BUG #2390: check constraint in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Andreas Kretschmer
 
Posts: n/a

Default [BUGS] BUG #2390: check constraint - 04-13-2006 , 08:59 AM







The following bug has been logged online:

Bug reference: 2390
Logged by: Andreas Kretschmer
Email address: andreas.kretschmer (AT) schollglas (DOT) com
PostgreSQL version: 8.1.3
Operating system: Debian Linux
Description: check constraint
Details:

i want to add a check constraint like:

create table foo (i char(7) CHECK (i ~ '^[0-9]{6,7}$'));

i doesn't work, but if works, if i change the type for i to varchar(7).

Bug or feature?

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Reply With Quote
  #2  
Old   
Stephan Szabo
 
Posts: n/a

Default Re: [BUGS] BUG #2390: check constraint - 04-13-2006 , 11:07 AM







On Wed, 12 Apr 2006, Andreas Kretschmer wrote:

Quote:
The following bug has been logged online:

Bug reference: 2390
Logged by: Andreas Kretschmer
Email address: andreas.kretschmer (AT) schollglas (DOT) com
PostgreSQL version: 8.1.3
Operating system: Debian Linux
Description: check constraint
Details:

i want to add a check constraint like:

create table foo (i char(7) CHECK (i ~ '^[0-9]{6,7}$'));

i doesn't work, but if works, if i change the type for i to varchar(7).
Well, the regex doesn't entirely make sense for char(n) data. It's not
possible to have 6 characters between beginning and end because it's a
fixed length 7 character string. If you try to insert '000000' into i,
you're actually inserting '000000 ' which is invalid by the constraint.


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


Reply With Quote
  #3  
Old   
Tom Lane
 
Posts: n/a

Default Re: [BUGS] BUG #2390: check constraint - 04-13-2006 , 11:44 AM



Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com> writes:
Quote:
On Wed, 12 Apr 2006, Andreas Kretschmer wrote:
i want to add a check constraint like:
create table foo (i char(7) CHECK (i ~ '^[0-9]{6,7}$'));

i doesn't work, but if works, if i change the type for i to varchar(7).

Well, the regex doesn't entirely make sense for char(n) data. It's not
possible to have 6 characters between beginning and end because it's a
fixed length 7 character string. If you try to insert '000000' into i,
you're actually inserting '000000 ' which is invalid by the constraint.
You could argue that since we consider trailing spaces not to be
semantically significant in char(n), it would be more consistent to
strip those spaces before performing the regex match. Currently the
system goes out of its way to cause the trailing spaces in the char(n)
value to be seen by the regex: there's actually a separate ~ operator
for bpchar. If we simply removed that, and let the normal char-to-text
promotion be invoked first, the match would work as Andreas expects.

I seem to recall that we've discussed this before, but don't remember if
the idea was actively rejected or just faded out of mind without being
implemented.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org


Reply With Quote
  #4  
Old   
Stephan Szabo
 
Posts: n/a

Default Re: [BUGS] BUG #2390: check constraint - 04-13-2006 , 12:09 PM




On Thu, 13 Apr 2006, Tom Lane wrote:

Quote:
Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com> writes:
On Wed, 12 Apr 2006, Andreas Kretschmer wrote:
i want to add a check constraint like:
create table foo (i char(7) CHECK (i ~ '^[0-9]{6,7}$'));

i doesn't work, but if works, if i change the type for i to varchar(7).

Well, the regex doesn't entirely make sense for char(n) data. It's not
possible to have 6 characters between beginning and end because it's a
fixed length 7 character string. If you try to insert '000000' into i,
you're actually inserting '000000 ' which is invalid by the constraint.

You could argue that since we consider trailing spaces not to be
semantically significant in char(n), it would be more consistent to
strip those spaces before performing the regex match.
Possibly, although I'm not sure that the particulars of how we treat
spaces in char(n) are precisely right either.

AFAIR, the spec doesn't talk about stripping spaces, it talks about
padding shorter values. That's usually the same, but for cases like this
one, I think it's different.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.