[HACKERS] UNION with more than 2 branches

2007-04-24 Thread Peter Eisentraut
The resolution to my problem with the select_common_type() error message turned out to be that this doesn't work: postgres=# select null union select null union select 1; ERROR: UNION types text and integer cannot be matched That's because it resolves the first two branches independently, then

Re: [HACKERS] UNION with more than 2 branches

2007-04-24 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: The resolution to my problem with the select_common_type() error message turned out to be that this doesn't work: postgres=# select null union select null union select 1; ERROR: UNION types text and integer cannot be matched Yeah, this has been

Re: [HACKERS] UNION with more than 2 branches

2007-04-24 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Maybe we should just ignore those qualms and do it anyway --- I must admit that I'm hard-pressed to come up with a situation where anyone would really want different datatypes used in the inner union than the outer. Does it even matter except in the case of

Re: [HACKERS] UNION with more than 2 branches

2007-04-24 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Maybe we should just ignore those qualms and do it anyway --- I must admit that I'm hard-pressed to come up with a situation where anyone would really want different datatypes used in the inner union than the outer.

Re: [HACKERS] UNION with more than 2 branches

2007-04-24 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Does it even matter except in the case of nulls? I mean, if the inner pair uses integer and then the outer pair uses bigint it'll still work correctly, no? Oh, it absolutely matters: you can get different answers.

Re: [HACKERS] UNION with more than 2 branches

2007-04-24 Thread Peter Eisentraut
Am Dienstag, 24. April 2007 19:48 schrieb Tom Lane: You're missing the point, which is that the inner UNION needs to decide what its uniqueness semantics are, independently of what might happen to its result later.  Or that's how I read the spec anyway. It's probably safer to leave it as is.