Tom Lane wrote:
> 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