Josh Berkus <[EMAIL PROTECTED]> writes:
>> Oh, why didn't you say so? Seems like the correct tool to solve that is
>> a partial unique index, not a constraint at all.
> Hmmm we support that?Darn, how do I miss these things. When did we
> start supporting it? Bric still has a lot of u
Tom,
> Oh, why didn't you say so? Seems like the correct tool to solve that is
> a partial unique index, not a constraint at all.
Hmmm we support that?Darn, how do I miss these things. When did we
start supporting it? Bric still has a lot of users who use 7.2.
--
-Josh Berkus
Ag
Josh Berkus <[EMAIL PROTECTED]> writes:
> BTW, the above is basically Bricolage's problem ... they
> want only active user names to be unique.
Oh, why didn't you say so? Seems like the correct tool to solve that is
a partial unique index, not a constraint at all.
regards
Tom,
> AFAIR, whether a constraint is syntactically attached to a column or is
> "loose" in the table definition is not supposed to have any semantic
> consequences, but I might be wrong about that too.
Well, a table-level CHECK constraint can attach to more than one column, so in
that way *is*
Tom,
> Is it? Our present handling of CHECK constraints cannot reasonably be
> thought to support anything but row-local constraints. If they're using
> a function to make an end-run around the check that prohibits subselects
> in CHECK constraints, then their problems are much more serious than
Tom Lane wrote:
Our present handling of CHECK constraints cannot reasonably be
thought to support anything but row-local constraints. If they're using
a function to make an end-run around the check that prohibits subselects
in CHECK constraints, then their problems are much more serious than
wh
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Isn't this already solved by dumping in dependency order?
> Nope. Problem is, the table depends on the function, and the function
> depends on the table. pg_dump (in 7.4.1, at least) will dump the table
> first, *with the constraint*, and then the f
Tom,
> Isn't this already solved by dumping in dependency order?
>
> regards, tom lane
Nope. Problem is, the table depends on the function, and the function
depends on the table. pg_dump (in 7.4.1, at least) will dump the table
first, *with the constraint*, and then th
Josh Berkus <[EMAIL PROTECTED]> writes:
> Last month, there was a discussion about deferring constraints that use
> user-defined functions to the end of the pg_dump file, like we do with FK
> constraints.Did this go anywhere, or is it still a TODO in search of an
> owner?
Isn't this already
Folks,
Last month, there was a discussion about deferring constraints that use
user-defined functions to the end of the pg_dump file, like we do with FK
constraints.Did this go anywhere, or is it still a TODO in search of an
owner?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
10 matches
Mail list logo
