From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Failure to coerce unknown type to specific type |
Date: | 2015-04-30 13:05:41 |
Message-ID: | CA+TgmobymzvoNZLwk-m_b3XTL8JQowyjLJyM8JkCyjhj5CrcvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Wed, Apr 29, 2015 at 6:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> We should, in fact, fail that to begin with. Unknown-type columns are
>>> a spectactularly horrid idea.
>
>> I agree. So why don't we throw an error when someone tries to create one?
>
> We should IMO, but there's been push-back about backwards compatibility
> when this has been proposed in the past.
I do think that there are probably people who have got cruft lying
around in their database where they've accidentally created views or
tables with unknown-type columns. They are unlikely to be actually
used, but they may exist. If we want to ease the
backward-compatibility pain, maybe we could map unknown -> text, so
that the upgrade still works but changes the column type under the
hood. Or we can just break it. But we should do something.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-30 13:08:39 | Re: Re: [BUGS] BUG #11805: Missing SetServiceStatus call during service shutdown in pg_ctl (Windows only) |
Previous Message | Robert Haas | 2015-04-30 13:02:36 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-30 13:08:39 | Re: Re: [BUGS] BUG #11805: Missing SetServiceStatus call during service shutdown in pg_ctl (Windows only) |
Previous Message | Bruce Momjian | 2015-04-30 13:02:55 | Re: Use outerPlanState() consistently in executor code |