From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: updated WIP: arrays of composites |
Date: | 2007-05-11 22:18:15 |
Message-ID: | 5585.1178921895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> That's not really the most preferable solution, I think, seeing that it
>> still leaves the user with the problem of having to create the types in
>> the right order to start with.
> I'm not sure we can keep the _foo convention and avoid that.
Auto-rename. I'm working on a patch now, and it doesn't look like it'll
be too awful. Will post it for comments when it's working.
> ... I'd vote to revert the new name
> mangling piece (but keep the typarray mapping column), deprecate the use
> of the _foo convention, and abandon it next release.
I came across a comment in the source that says PG has been using _foo
for arrays since 3.1 (!). I don't think we can get away with changing
it, certainly not with only one release cycle's notice.
The current code is OK from a compatibility point of view, since it only
changes _foo to something else in situations where the old way would've
failed outright. I think we need to preserve that property ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-05-11 22:26:06 | Re: updated WIP: arrays of composites |
Previous Message | Heikki Linnakangas | 2007-05-11 22:14:56 | Doc update for back-branches, CLUSTER and MVCC-safety |