From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding time to DATE type |
Date: | 2000-06-12 17:10:00 |
Message-ID: | 1512.960829800@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian writes:
>> Can someone give me a TODO summary for this issue?
> * make 'text' constants default to text type (not unknown)
> (I think not everyone's completely convinced on this issue, but I don't
> recall anyone being firmly opposed to it.)
It would be a mistake to eliminate the distinction between unknown and
text. See for example my just-posted response to John Cochran on
pgsql-general about why 'BOULEVARD'::text behaves differently from
'BOULEVARD'::char. If string literals are immediately assigned type
text then we will have serious problems with char(n) fields.
I think it's fine to assign string literals a type of 'unknown'
initially. What we need to do is add a phase of type resolution that
considers treating them as text, but only after the existing logic fails
to deduce a type.
(BTW it might be better to treat string literals as defaulting to char(n)
instead of text, allowing the normal promotion rules to replace char(n)
with text if necessary. Not sure if that would make things more or less
confusing for operations that intermix fixed- and variable-width char
types.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-06-12 17:12:38 | Re: ALTER TABLE DROP COLUMN |
Previous Message | Bruce Momjian | 2000-06-12 16:41:21 | Re: pgsql (Makefile) |