On Tue, 2021-08-17 at 10:45 -0700, Paul Martinez wrote:
> On Tue, Aug 17, 2021 at 8:41 AM Jack Christensen wrote:
> > The only way to ensure a user can only be a member of a group in the same
> > tenant is to user_group_memberships.tenant_id be part of the foreign key.
> > And
> > that will only
On Tue, Aug 17, 2021 at 8:41 AM Jack Christensen wrote:
>
> The only way to ensure a user can only be a member of a group in the same
> tenant is to user_group_memberships.tenant_id be part of the foreign key. And
> that will only work with a unique key on id and tenant_id in both users and
>
On Mon, Aug 16, 2021 at 7:01 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Aug 16, 2021 at 4:37 PM Paul Martinez wrote:
>
>>
>> It seems like a somewhat useful feature. If people think it would be
>> useful to
>> implement, I might take a stab at it when I have time.
>>
>>
On Mon, Aug 16, 2021 at 4:37 PM Paul Martinez wrote:
>
> It seems like a somewhat useful feature. If people think it would be
> useful to
> implement, I might take a stab at it when I have time.
>
>
This doesn't seem useful enough for us to be the only implementation to go
above and beyond the
Hey, hackers!
While working with some foreign keys, I noticed some mildly unexpected
behavior. The columns referenced by a unique constraint must naturally
have a unique constraint on them:
CREATE TABLE foo (a integer);
CREATE TABLE bar (x integer REFERENCES foo(a));
> ERROR: there is no unique
