In-Reply-To: <4523D8B1.7050007@logix-tt.com>
References: <45218F90.1050303@logix-tt.com>
	<794403F6-6CB5-4726-806C-5EF76D64C7E3@themactionfaction.com>
	<34B58049-42F3-468D-AA2A-AE79DC8FB244@decibel.org>
	<45222B63.2070608@logix-tt.com> <26117.1159889582@sss.pgh.pa.us>
	<452381C8.5090804@logix-tt.com> <4523C28F.4080404@dunslane.net>
	<4523D8B1.7050007@logix-tt.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <06013250-FEB2-431C-9EE9-DB4CB037FE9E@enterprisedb.com>
Cc: PostgreSQL-development hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: 7bit
From: Jim Nasby <jimn@enterprisedb.com>
Subject: Re: timestamptz alias
Date: Thu, 5 Oct 2006 21:18:40 -0500
To: Markus Schaber <schabi@logix-tt.com>

On Oct 4, 2006, at 10:52 AM, Markus Schaber wrote:
> Andrew Dunstan wrote:
>>> It's not only about documenting the pure existence of the aliases  
>>> (which
>>> was already documented in the table on the datatype TOC page),  
>>> it's also
>>> about telling the user which of the names are the ones to avoid,  
>>> and the
>>> reasons to do so.
>>
>> *blink* Why do any need to be avoided? What you use is a matter of
>> taste, and your organisation's coding standards. From a purely  
>> technical
>> POV I don't see any reason to avoid using either the canonical type
>> names or the various aliases.
>
> At least compatibility with the SQL standard, as well as with other
> Databases might be a reason.

It would be nice to denote types/aliases that are and aren't ANSI. A  
number are marked  in the docs, but it would be good to add the info  
to that summary table.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


--
Jim Nasby                                    jimn@enterprisedb.com
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)