Alvaro Herrera writes:
> Tom Lane wrote:
>> What we need is a unique index on pg_constraint.
>> The problem with that is that pg_constraint contains both table-related
>> and type (domain) related constraints; but it strikes me that we could
>> probably create a unique
Tom Lane wrote:
> What we need is a unique index on pg_constraint.
>
> The problem with that is that pg_constraint contains both table-related
> and type (domain) related constraints; but it strikes me that we could
> probably create a unique index on (conrelid, contypid, conname).
Weren't you
Andrew Dunstan writes:
> On 03/30/2016 10:21 AM, Tom Lane wrote:
>> I think that if we want to ensure uniqueness of constraint names, this
>> is really approaching it the wrong way, as it still fails to provide
>> any guarantees (consider concurrent index creation, for
On 03/30/2016 10:21 AM, Tom Lane wrote:
Amit Langote writes:
On 2016/03/30 15:16, Harshal Dhumal wrote:
If we create two different type of constrains (lets say primary key and
foreign key) on same table with same name (lets say 'key' ) then its shows
same drop
Amit Langote writes:
> On 2016/03/30 15:16, Harshal Dhumal wrote:
>> If we create two different type of constrains (lets say primary key and
>> foreign key) on same table with same name (lets say 'key' ) then its shows
>> same drop query for both constrains.
I have
On 2016/03/30 15:16, Harshal Dhumal wrote:
> Hi Team,
>
> While I was working on constraints node in pgadmin4 I came across this
> scenario. Please let me know if it's correct behaviour or a bug.
>
> *Scenario:*
>
> If we create two different type of constrains (lets say primary key and
>
Hi Team,
While I was working on constraints node in pgadmin4 I came across this
scenario. Please let me know if it's correct behaviour or a bug.
*Scenario:*
If we create two different type of constrains (lets say primary key and
foreign key) on same table with same name (lets say 'key' ) then