Re: SQL0203 - Name xxxx is ambiguous, when using JOIN USING

John,

I don't use USING much myself, primarily since every system I've been on
has old school DDS defined files with a prefix character in the field names.

But my newer development does have common column names without prefixing,
and long ones at that. Not to mention composite keys. So when doing
ad-hoc queries, it's a lot nicer to be able to use USING when I can.

Charles

Charles

On Tue, Oct 21, 2014 at 5:49 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Tue, Oct 21, 2014 at 5:02 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Interestingly, neither DB2 10.5 for LUW nor DB2 10 for z/OS support the
JOIN USING syntax at all. So I guess it's nice to get something first,

but

then of course you get to work the bugs out!

I guess "nice" is one way to look at it.

I've always gotten the impression that DB2's flavor of SQL is more
conservative than others; that it strives to stick to "standard" SQL,
only reluctantly adding "optional standard" features (like USING) and
actively avoiding nonstandard features.

This is good and bad, but I think IBMers tend to focus on the good,
both because that's the database they've got, and because the IBM
culture tends to value conservatism.

I've been trying to go with this flow, and that's one reason why I
specifically recommended not bothering with USING and just using ON.
The other reason is that I prefer having fewer but more general
language constructs. For me, USING just doesn't feel like a big
enough improvement over ON to be worth keeping that extra keyword
around in my vocabulary, which I can't use anyway if I find myself
talking to certain other databases.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.