| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Couple document fixes |
| Date: | 2011-09-06 15:19:45 |
| Message-ID: | 7024.1315322385@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote:
>> What would be the point?
> Removing the legacy "char" type, per original post. :)
Removing it is the wrong solution.
The idea of renaming it to char1 might be an appropriate balance of pain
versus benefit. Or perhaps not; I'd want to see a proposed patch before
committing to doing anything here.
> We've made changes as big on aesthetic grounds before, and if the
> change results in an enum type optimized for space efficiency, that's
> all to the good.
That's a pipe dream. You can't use enums in catalogs that underlie the
enum implementation. Possibly you could kluge something so that there
are phony entries in pg_enum reflecting the hard-wired values that the C
code uses, but I entirely fail to see any point in such a thing.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-09-06 15:52:32 | Re: about value storage |
| Previous Message | Bruce Momjian | 2011-09-06 15:08:51 | Re: number of semaphores and semaphore sets |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ants Aasma | 2011-09-06 15:40:04 | Re: [COMMITTERS] pgsql: Clean up the #include mess a little. |
| Previous Message | Robert Haas | 2011-09-06 14:42:03 | Re: B-tree parent pointer and checkpoints |