Stephan Szabo wrote:
> On Wed, 17 May 2006, Tom Lane wrote:
>
>
>>Stephan Szabo <[EMAIL PROTECTED]> writes:
>>
>>>Per the report from Clark C Evans a while back and associated discussion,
>>>it seems like recent versions of the SQL spec changed the rules for
>>>foreign key column references such
On Wed, 17 May 2006, Tom Lane wrote:
> I'm more inclined to think that we've messed up the information_schema
> somehow ...
As usual, you're right. ;)
Actually, it wasn't precisely that we messed it up as much as the 99
defintion was wrong. It's pointed out in the 2003 schemata
incompatibilities
Stephan Szabo <[EMAIL PROTECTED]> writes:
> That seems like a very odd way to phrase that since just saying that the
> sets of column names are equivalent would be enough for that and all the
> extra words seem to only obscure the point.
As an example of clear well-written English, it certainly fa
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 17 May 2006, Tom Lane wrote:
>> where SQL2003 has
>>
>> If the specifies a > list>, then there shall be a one-to-one correspondence between the
>> set of s contained in that
>> and the set of s contained in the > list> of a
On Wed, 17 May 2006, Stephan Szabo wrote:
> On Wed, 17 May 2006, Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > Per the report from Clark C Evans a while back and associated discussion,
> > > it seems like recent versions of the SQL spec changed the rules for
> > > foreign
On Wed, 17 May 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Per the report from Clark C Evans a while back and associated discussion,
> > it seems like recent versions of the SQL spec changed the rules for
> > foreign key column references such that the columns of the refe
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Per the report from Clark C Evans a while back and associated discussion,
> it seems like recent versions of the SQL spec changed the rules for
> foreign key column references such that the columns of the referenced
> unique constraint must be named in or
Now that I've got a little time again...
Per the report from Clark C Evans a while back and associated discussion,
it seems like recent versions of the SQL spec changed the rules for
foreign key column references such that the columns of the referenced
unique constraint must be named in order (th
