>
> On Mon, Oct 25, 2010 at 15:11, Peter Eisentraut wrote:
>
>> Example #4: PK is period, FK is timestamp. FK must be contained in some
>> PK period.
>>
>> CREATE TABLE pk (a period PRIMARY KEY, ...);
>>
>> CREATE TABLE fk (x timestamp REFERENCES pk (a), ...);
>>
>> As above, we can probably arra
On Mon, Oct 25, 2010 at 15:11, Peter Eisentraut wrote:
> Example #4: PK is period, FK is timestamp. FK must be contained in some
> PK period.
>
> CREATE TABLE pk (a period PRIMARY KEY, ...);
>
> CREATE TABLE fk (x timestamp REFERENCES pk (a), ...);
>
> As above, we can probably arrange the opera
On 10/26/10 11:53 AM, Jeff Davis wrote:
> Intuitively, I would expect all 1's to be replaced by 6's in all arrays.
> But I can now see why you would be hesitant to try to support that.
If people want cascading update to work, they shouldn't be denormalizing.
--
On tis, 2010-10-26 at 11:53 -0700, Jeff Davis wrote:
> Case #2 is the strange one, I think. It's not actually just an
> adaptation of #1. #1 requires that all elements of the array have a
> corresponding PK value; but #2 just requires that one of them does.
> Peter, can you clarify case #2? Did you
On Mon, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis wrote:
> > I think that's easier when the PK must contain the FK, because then you
> > only need to lock one record. Even when you need to lock multiple
> > records, it seems feasible, and is just an
On Tue, 2010-10-26 at 20:25 +0300, Peter Eisentraut wrote:
> Let's say you have
>
> PK
>
> 1
> 2
> 3
> 4
> 5
>
> FK
>
> [1,2,3]
> [3,4,5]
> [4,4,4]
>
> When you delete PK = 3, what do you expect to happen? OK, you might
> decide to delete the first two rows from the FK table. This might or
On mån, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
> Well if you lock multiple records then it's not clear what operations
> you should conflict with. Removing any one of them wouldn't actually
> invalidate the foreign key reference unless you remove the last one.
>
> I always assumed this was w
On mån, 2010-10-25 at 17:38 -0700, Jeff Davis wrote:
> > Implementing the foreign key side of this merely requires the system
> to
> > have some knowledge of the required "contains" operator, which it
> does
> > in the array case, and something can surely be arranged for the
> range
> > case. The
On mån, 2010-10-25 at 22:10 +0200, Pavel Stehule wrote:
> 2010/10/25 Robert Haas :
> >> Example #1: Foreign key side is an array, every member must match some
> >> PK.
> >>
> >> CREATE TABLE pk (a int PRIMARKY KEY, ...);
> >>
> >> CREATE TABLE fk (x int[] REFERENCES pk (a), ...);
>
> What about op
On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis wrote:
> I think that's easier when the PK must contain the FK, because then you
> only need to lock one record. Even when you need to lock multiple
> records, it seems feasible, and is just an index lookup, right? Do you
> see a particular problem?
Wel
On Mon, 2010-10-25 at 22:11 +0300, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
I agr
On Mon, 2010-10-25 at 12:34 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> > Is this sort of thing feasible? Has anyone done more research into the
> > necessary details?
>
> I think the problems arise when you try to figure out what records you
> need to
2010/10/25 Robert Haas :
> On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
>> Currently, foreign keys only work with the = operator (the name might be
>> different, but it needs to behave like equality). I'm thinking there
>> are other scenarios that could be useful, for example with arr
On Mon, Oct 25, 2010 at 3:11 PM, Peter Eisentraut wrote:
> Currently, foreign keys only work with the = operator (the name might be
> different, but it needs to behave like equality). I'm thinking there
> are other scenarios that could be useful, for example with arrays and
> range types.
>
> Exa
On Mon, Oct 25, 2010 at 12:11 PM, Peter Eisentraut wrote:
> Is this sort of thing feasible? Has anyone done more research into the
> necessary details?
I think the problems arise when you try to figure out what records you
need to lock to prevent someone from deleting the referenced rows
before
Currently, foreign keys only work with the = operator (the name might be
different, but it needs to behave like equality). I'm thinking there
are other scenarios that could be useful, for example with arrays and
range types.
Example #1: Foreign key side is an array, every member must match some
P
16 matches
Mail list logo
