Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP id 7E6AB47596A
	for <pgsql-hackers@postgresql.org>;
	Tue, 16 Jul 2002 09:44:49 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g6GDiEAl012278;
	Tue, 16 Jul 2002 09:44:14 -0400 (EDT)
To: Thomas Lockhart <lockhart@fourpalms.org>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Tim Hart <tjhart@mac.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] line datatype 
In-reply-to: <3D33B8D5.D8A2E1CE@fourpalms.org> 
References: <200207160333.g6G3Xnc22777@candle.pha.pa.us>
	<3D33B8D5.D8A2E1CE@fourpalms.org>
Comments: In-reply-to Thomas Lockhart <lockhart@fourpalms.org>
	message dated "Mon, 15 Jul 2002 23:10:29 -0700"
Date: Tue, 16 Jul 2002 09:44:14 -0400
Message-ID: <12277.1026827054@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200207/637
X-Sequence-Number: 25011

Thomas Lockhart <lockhart@fourpalms.org> writes:
> The issue is in choosing an external format for LINE which does not lose
> precision during dump/reload.

Why is this any worse for LINE than for any of the other geometric
types (or for plain floats, for that matter)?

We do need a solution for exact dump/reload of floating-point data,
but I don't see why the lack of it should be reason to disable access
to the LINE type.

			regards, tom lane