Richard Huxton <dev@archonet.com> writes:
Yann Michel wrote:
I think you mean UNION ALL, i.e. the set addition, don't you?
Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct.
If a unique key of the underlying table is included in the UNION data, then there can't be any duplicate rows and so the UNION really reduces to UNION ALL. However, I'm unconvinced that there are any cases like this that are interesting in practice. Consider
CREATE TABLE a (id int primary key, ...);
CREATE TABLE b (id int primary key, ...);
CREATE VIEW v AS SELECT * FROM a UNION SELECT * FROM b;
If a and b have disjoint key sets then the UNION is theoretically updatable, but there is no way to specify such a constraint and thus no way for the system to know that the UNION is updatable.
What about: CREATE TABLE a(id int primary key check < 100, ...) CREATE TABLE b(id int primary key check > 100, ...)
In any case, imagine a diary system where you might have an booking involving one or more people and/or resources (room/projector). You'd quite possibly have:
SELECT 'P' as res_type, p_id, p_name FROM event_person UNION SELECT 'R', r_id, r_type FROM event_resource WHERE ...
Again, updatable (although I'm not sure how you'd detect the implied CHECK on the first column).
None of this is easy, or even practical but I'm fairly sure it's all possible.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
