Received: from candle.pha.pa.us (216-55-132-35.dsl.san-diego.abac.net [216.55.132.35]) by postgresql.org (Postfix) with ESMTP id D4F3147594E for ; Tue, 16 Jul 2002 11:21:29 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id g6GFL5417443; Tue, 16 Jul 2002 11:21:05 -0400 (EDT) From: Bruce Momjian Message-Id: <200207161521.g6GFL5417443@candle.pha.pa.us> Subject: Re: [SQL] line datatype In-Reply-To: <12277.1026827054@sss.pgh.pa.us> To: Tom Lane Date: Tue, 16 Jul 2002 11:21:05 -0400 (EDT) Cc: Thomas Lockhart , Tim Hart , PostgreSQL-development X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200207/639 X-Sequence-Number: 25013 Tom Lane wrote: > Thomas Lockhart 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. I don't understand why dumping the two point values isn't sufficient. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026