Niklas Johansson <[EMAIL PROTECTED]> writes:
> You must cast the integer column to a float or numeric, try:
Since the CHECK is expecting an exact result, better use numeric.
regards, tom lane
---(end of broadcast)---
TIP 5:
On 17 maj 2006, at 08.42, Risto Tamme wrote:
INSERT INTO "PART" ("P_PARTKEY","P_RETAILPRICE") VALUES(999,90109.89);
but it fails: ERROR: new row for relation "PART" violates check
constraint "PART_check"
The P_PARTKEY column is an integer, which means the expression
P_PARTKEY/10 will yield
Hello
I use PostgreSQL in my program and I found a strange behavior, at least
for me.
I have a simple table with constraint
CREATE TABLE "PART"
(
"P_PARTKEY" int4 NOT NULL,
"P_RETAILPRICE" numeric,
CONSTRAINT "PART_PRIMARY" PRIMARY KEY ("P_PARTKEY"),
CONSTRAINT "PART_check" CHECK ("P_RET
On Tue, 2005-03-01 at 09:56 -0700, Greg Patnude wrote:
> foreign keys and primary keys have to be defined as unique at the
> table /
> column level if you want to implement a check constraint -- your
> contrived
> example doesn't stand up all that well -- If you want to use
> constraints --
> then
foreign keys and primary keys have to be defined as unique at the table /
column level if you want to implement a check constraint -- your contrived
example doesn't stand up all that well -- If you want to use constraints --
then your database schema should conform to traditional RDBMS theory a
On Mon, 2005-02-28 at 18:01 -0700, Andrew - Supernews wrote:
> The CHECK is obviously being evaluated prior to the actual insertion
> of
> the record, whereas the logic of your function clearly expects to be
> evaluated after the insertion.
>
I finally came to that conclusion just a few minutes b
On 2005-02-28, "Casey T. Deccio" <[EMAIL PROTECTED]> wrote:
> However, the example I provided was contrived and was used merely to
> show the discrepancy that I'm finding with using the function as a
> constraint. In the larger example, things are a bit more complex, and
> I've found using such a
On Mon, 2005-02-28 at 13:20 -0700, Bruno Wolff III wrote:
> On Mon, Feb 28, 2005 at 11:28:30 -0800,
> "Casey T. Deccio" <[EMAIL PROTECTED]> wrote:
> >
> > In this case each bldg has an owner associated to it, and each
> animal
> > lives in some bldg. Each owner has exactly one own favorite anima
On Mon, Feb 28, 2005 at 11:28:30 -0800,
"Casey T. Deccio" <[EMAIL PROTECTED]> wrote:
>
> In this case each bldg has an owner associated to it, and each animal
> lives in some bldg. Each owner has exactly one own favorite animal out
> of all the bldgs owned by him. So the constraint added to ea
Hi,
I am running PostgreSQL 7.4.7. I am having some issues with a
constraint for one of my database tables. The code snippet below
outlines the code and its output (output is commented).
In this case each bldg has an owner associated to it, and each animal
lives in some bldg. Each owner has ex
"David Allardyce" <[EMAIL PROTECTED]> writes:
> ... If they had defined uniqueness as "all rows
> must be distinct" then two all null rows would violate the uniqueness
> constraint. Not the behavior I want at all.
Er, why not? You're essentially arguing that the UNIQUE constraint
should treat n
I don't mean to re-hash an argument that has been debated-to-death before,
but I can't help myself...
> > However, shouldn't any values that are not NULL violate the constraint
if
> > the same values exist already?
>
> No. Postgres is conforming to the SQL standard in this. SQL92 saith
> in sec
"David Allardyce" <[EMAIL PROTECTED]> writes:
> However, shouldn't any values that are not NULL violate the constraint if
> the same values exist already?
No. Postgres is conforming to the SQL standard in this. SQL92 saith
in section 4.10:
A unique constraint is satisfied if and only
It appears that Postgres will allow any INSERT, despite a multiple-column
constraint, if any of the values INSERTed are NULL. If I read the included
excerpt correctly (there are like three negatives in the second sentence,
sheesh :) ), multiple NULL values for a column are acceptable or, in other
14 matches
Mail list logo
