Re: XMIN/xid vs UNION

#1

Try a cast, or just use UNION ALL

On Fri, Oct 29, 2004 at 04:44:37PM +0200, Karsten Hilbert wrote:

Quote:

Dear all,

some of my views are created with help of the UNION operator.
Now, I also need to include the base table XMIN system column
into those views. Which works fine (as long as I alias them)
except that UNION does an internal sort. My PG version (7.4)
complains about not being able to find a sort operator for
data type XID (of which XMIN is).

Searching the web unearthes a solution for loading those
missing operators for as early as 6.4.1 (1998) !

http://archives.postgresql.org/pgsql...1/msg00096.php

Strangely enough I see those operators listed in the release
notes for 7.2 ...

http://www.postgresql.org/docs/7.2/i...lease-7-2.html

Are those operators included in PG > 7.4 ? Should they be ? Is
it my version that's compiled without them, perhaps ?

Thanks,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/

Quote:

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBgmdTY5Twig3Ge+YRArYjAJ9VXQ5rKhvcutM0uusgU5 NXu/g8CACg2gLH
WivWg6V52cnXFrvl2Bp01co=
=l9YH
-----END PGP SIGNATURE-----

#2

Quote:

Try a cast, or just use UNION ALL
Thanks.

Casting didn't work (it was missing the proper cast function
from xid to int4) but using UNION ALL worked. This was also
possible to use in my case since both parts of the UNION do
indeed return distinct sets of rows so UNION ALL does not
produce duplicates.

However, the question still holds true: Is there any
particular reason those operators aren't found in my PG
installation despite being listed as added since 7.2 ?
IOW why does
select 1::xid::int2/int4/int8
fail (on 7.4) despite 7.2 docs suggesting it should work ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

#3

Karsten Hilbert <Karsten.Hilbert (AT) gmx (DOT) net> writes:

Quote:

However, the question still holds true: Is there any
particular reason those operators aren't found in my PG
installation despite being listed as added since 7.2 ?

The only thing that was added in 7.2 was xid equality.

There was some talk recently of adding the other comparison operations,
but I'm not sure it's a good idea. For many purposes you'd want such
comparison operators to use the same semantics as TransactionIdPrecedes
(ie, compare mod 2^31) but that would mean that some of the usual
arithmetic laws break down (no transitive law, no triangle inequality)
and in particular you could not sort or build a btree index with such
operators. Which in turn means that you still wouldn't get the behavior
you wanted of having UNION or ORDER BY "just work".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: XMIN/xid vs UNION

comp.databases.postgresql.general comp.databases.postgresql.general

Re: XMIN/xid vs UNION - 10-29-2004 , 10:52 AM

Re: XMIN/xid vs UNION - 10-29-2004 , 04:51 PM

Re: XMIN/xid vs UNION - 10-29-2004 , 05:27 PM