| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Phil Currier <pcurrier(at)gmail(dot)com> |
| Subject: | Re: logical column ordering |
| Date: | 2015-03-12 14:07:51 |
| Message-ID: | 20150312140751.GB20199@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2015-03-11 22:16:52 -0400, Tom Lane wrote:
> I agree though that it's worth considering defining pg_attribute.attnum as
> the logical column position so as to minimize the effects on client-side
> code.
I actually wonder if it'd not make more sense to define it as the
physical column number. That'd reduce the invasiveness and risk of the
patch considerably. It means that most existing code doesn't have to be
changed and can just continue to refer to attnum like today. There's
much less risk of it being wrongly used to refer to the physical offset
instead of creation order. Queries against attnum would still give a
somewhat sane response.
It would make some ALTER TABLE commands a bit more complex if we want to
allow reordering the physical order. But that seems like a much more
localized complexity than previous patches in this thread (although I've
not looked at the last version).
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-03-12 14:08:54 | Re: pg_dump: CREATE TABLE + CREATE RULE vs. relreplident |
| Previous Message | Tom Lane | 2015-03-12 14:00:40 | Re: OOM-killer issue when updating a inheritance table which has large number of child tables |