From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | AgentM <agentm(at)themactionfaction(dot)com> |
Cc: | PostgreSQL-development hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: timestamptz alias |
Date: | 2006-10-03 01:26:51 |
Message-ID: | 34B58049-42F3-468D-AA2A-AE79DC8FB244@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Oct 2, 2006, at 6:22 PM, AgentM wrote:
> On Oct 2, 2006, at 18:15 , Markus Schaber wrote:
>> I'm happy that the rather verbose "timestamp with time zone" has the
>> much nicer alias "timestamptz", however it seems that this alias
>> is not
>> documented, neither at
>> http://developer.postgresql.org/pgdocs/postgres/datatype-
>> datetime.html
>> nor at http://www.postgresql.org/docs/8.1/interactive/datatype-
>> datetime.html
>>
>> I see it mentioned at
>> http://www.postgresql.org/docs/8.1/interactive/datatype.html but
>> that's
>> possibly not where people look at first, when they search for the
>> timestamp type. (At least I found it only when grepping for
>> "timestamptz" in the docs. :-)
>>
>> Should the alias be mentioned on the datetime page? The same for
>> timetz?
>> What do you think?
>
> I am pleased that the documentation promotes database-independent
> ("standard") SQL.
There's a difference between promoting and withholding info. I'd
rather see us explicitly state which is preferred and why.
BTW, another confusing example is all the string functions that are
essentially the same, such as substring and substr. (http://
www.postgresql.org/docs/8.1/interactive/functions-string.html)
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-10-03 09:20:35 | Re: timestamptz alias |
Previous Message | Bruce Momjian | 2006-10-03 00:43:46 | Re: Texinfo docs/target |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2006-10-03 01:43:01 | Re: Patch: Tie stats options to autovacuum in |
Previous Message | Jim Nasby | 2006-10-03 01:21:45 | Re: NULL and plpgsql rows |