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
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
"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
11 matches
Mail list logo
