On 2013-10-10 02:10, Robert Haas wrote:
I agree with these concerns, as well as those raised by Tom Lane and
Fabien COELHO, and I think they indicate that we shouldn't accept
this
patch. So I'm marking this as Rejected.
On 2013-10-11 06:48, Jim Nasby wrote:
I see a use case for disabling
On 10/9/13 1:10 PM, Robert Haas wrote:
On Tue, Sep 24, 2013 at 10:40 PM, Peter Eisentraut wrote:
On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
Hmm not sure i understand this argument either: this patch doesn't
allow disabling a primary key. It only supports FKs and CHECK
constraints e
On Tue, Sep 24, 2013 at 10:40 PM, Peter Eisentraut wrote:
> On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
>> Hmm not sure i understand this argument either: this patch doesn't
>> allow disabling a primary key. It only supports FKs and CHECK
>> constraints explicitly.
>
> Well, as soon as
On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
> Hmm not sure i understand this argument either: this patch doesn't
> allow disabling a primary key. It only supports FKs and CHECK
> constraints explicitly.
Well, as soon as the patch for cataloging not-null constraints as check
constraints
On Tue, Sep 24, 2013 at 5:58 AM, Bernd Helmle wrote:
> --On 13. September 2013 20:17:19 -0400 Robert Haas
> wrote:
>> You're missing the point. Peter wasn't worried that your patch throws
>> an error; he's concerned about the fact that it doesn't.
>>
>> In PostgreSQL, you can only create the fol
--On 13. September 2013 20:17:19 -0400 Robert Haas
wrote:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it doesn't.
In PostgreSQL, you can only create the following view because test1
has a primary key over column a:
=>
On Thu, Sep 12, 2013 at 10:03 PM, wrote:
> Second, I tested the check and the foreign key constraint as your test
> above.
> And no error found, as fellow:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it doesn't.
In PostgreS
On 09/13/2013 05:23, Peter Eisentraut wrote:
=> create table test1 (a int constraint pk primary key, b text);
=> create view test2 as select a, b from test1 group by a;
=> alter table test1 drop constraint pk;
ERROR: 2BP01: cannot drop constraint pk on table test1 because other
objects depend on
On 9/11/13 1:09 AM, wangs...@highgo.com.cn wrote:
> Peter Eisentraut wrote:
>> Note that other schema objects can depend on the existence of
>> constraints. For example, the validity of a view might depend on the
>> existence of a primary key constraint. What would you do with the view
>> if the
于 2013-09-09 20:54, Peter Eisentraut 回复:
On 9/3/13 3:13 AM, wangs...@highgo.com.cn wrote:
Drop/build and disable/enable constraint has no fundamental
difference,
and could achieve the same purpose.What I do also more convenient
for
the user.
Recording the disabled constraints is easier than re
On 9/3/13 3:13 AM, wangs...@highgo.com.cn wrote:
> Drop/build and disable/enable constraint has no fundamental difference,
> and could achieve the same purpose.What I do also more convenient for
> the user.
> Recording the disabled constraints is easier than recoding all the
> constrains.
Note tha
On Thu, Sep 5, 2013 at 12:27 PM, wrote:
> I had committed the patch to the Server Features
> (https://commitfest.postgresql.org/action/commitfest_view/open).
> Is this right ? If not, please give me more advice,thanks !
Yes this category is fine don't worry.
--
Michael
--
Sent via pgsql-hacke
于 2013-09-05 01:56, Robert Haas 回复:
On Tue, Sep 3, 2013 at 3:13 AM, wrote:
于 2013-09-03 08:15, David Johnston 回复:
Jeff Davis-8 wrote
Is there any semantic difference between marking a constraint as
DISABLED and simply dropping it? Or does it just make it easier to
re-add it later?
Davi
On Tue, Sep 3, 2013 at 3:13 AM, wrote:
> 于 2013-09-03 08:15, David Johnston 回复:
>
>> Jeff Davis-8 wrote
>>>
>>> Is there any semantic difference between marking a constraint as
>>> DISABLED and simply dropping it? Or does it just make it easier to
>>> re-add it later?
>>
>>
> David Johnston wrote
于 2013-09-03 08:15, David Johnston 回复:
Jeff Davis-8 wrote
Is there any semantic difference between marking a constraint as
DISABLED and simply dropping it? Or does it just make it easier to
re-add it later?
David Johnston wrote:
I cannot answer the question but if there is none then the main
Jeff Davis-8 wrote
> Is there any semantic difference between marking a constraint as
> DISABLED and simply dropping it? Or does it just make it easier to
> re-add it later?
I cannot answer the question but if there is none then the main concern I'd
have is capturing "meta-information" about WHY s
On Fri, 2013-08-30 at 09:57 +0800, wangs...@highgo.com.cn wrote:
> Hi hackers,
>
>In order to achieve enable/disable constraint name，I made a few
> modifications to the code.
>
>First, someone used to build the constraints while building
> table. Then inserting data must follo
于 2013-08-30 21:27, Tom Lane 回复:
wangs...@highgo.com.cn writes:
In order to achieve enable/disable constraint name，I made a
few
modifications to the code.
First, someone used to build the constraints while building
table. Then inserting data must follow a certain order.
A
Uh ... why not just drop the constraint, and re-add it later if you want
it again?
My 0.02€ : maybe because you must keep track of the constraint details to
do so, this it is significantly more error prone than disable / enable
when the bookkeeping is done by the system and if everything is
wangs...@highgo.com.cn writes:
>In order to achieve enable/disable constraint nameï¼I made ââa
> few
> modifications to the code.
>First, someone used to build the constraints while building
> table. Then inserting data must follow a certain order.
>And people usuall
20 matches
Mail list logo
