Re: BUG #5225: create table: cast necessary for constant?? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5225: create table: cast necessary for constant??
Date
Msg-id 24832.1259797184@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5225: create table: cast necessary for constant??  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: BUG #5225: create table: cast necessary for constant??
Re: BUG #5225: create table: cast necessary for constant??
List pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
> (ISO-ANSI Working Draft) Foundation (SQL/Foundation)":
> | 13) The declared type of a <character string literal> is
> |     fixed-length character string.
> Treating an otherwise unadorned set of characters between two
> apostrophes as anything except a character string literal of type
> CHARACTER with a length calculated per the above violates the
> standard.  Rather than pretending otherwise, we should be prepared
> to explain the reasons for the deviation, describe what the
> PostgreSQL behavior *is*, and justify the deviation.

Sorry about that --- I had confused this case with that of a bare NULL
literal, which Postgres treats the same as an unadorned string literal
for type determination purposes.  You're right that the spec treats
them differently.  This is feasible for the spec's purposes because
it has such a paucity of data types.  Also, I believe that the spec
expects you to explicitly mark literals that aren't to be treated
as plain strings, ie, in something like
    TIMESTAMP '2009-12-02 18:28:58'
you're not really supposed to omit the word TIMESTAMP.

Postgres has a whole lot of datatypes, including user-added ones, and
most of them share the unadorned string literal as the base case for
constants.  Giving preference to CHARACTER would make that machinery
a lot less pleasant to use.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Michal Pasternak"
Date:
Subject: BUG #5227: please add a divide operator for intervals
Next
From: Tom Lane
Date:
Subject: Re: BUG #5227: please add a divide operator for intervals