t_self as system column
in [PgSql]
|
From: Tom Lane on 5 Jul 2010 14:08 Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: > Is there a reason we don't have t_self as one of the system columns that > you can examine from SQL? I'd propose its addition otherwise. pg_attribute bloat? I'm a bit hesitant to add a row per table for something we've gotten along without for so long, especially something with as bizarre a definition as "t_self" has got. At one time I was hoping to get rid of explicit entries in pg_attribute for system columns, which would negate this concern. I think we're stuck with them now, though, because of per-column permissions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 5 Jul 2010 15:20 On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre(a)alvh.no-ip.org> writes: >> Is there a reason we don't have t_self as one of the system columns that >> you can examine from SQL? �I'd propose its addition otherwise. > > pg_attribute bloat? �I'm a bit hesitant to add a row per table for > something we've gotten along without for so long, especially something > with as bizarre a definition as "t_self" has got. > > At one time I was hoping to get rid of explicit entries in pg_attribute > for system columns, which would negate this concern. �I think we're > stuck with them now, though, because of per-column permissions. Because someone might want to grant per-column permissions on those columns? That seems like an awfully thin reason to keep all that bloat around. I bet the number of people who have granted per-column permissions on, say, cmax can be counted on one hand - possibly with five fingers left over. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 5 Jul 2010 15:26 Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> At one time I was hoping to get rid of explicit entries in pg_attribute >> for system columns, which would negate this concern. �I think we're >> stuck with them now, though, because of per-column permissions. > Because someone might want to grant per-column permissions on those > columns? That seems like an awfully thin reason to keep all that > bloat around. I bet the number of people who have granted per-column > permissions on, say, cmax can be counted on one hand - possibly with > five fingers left over. I'd agree with that argument for the most part, but I'm not entirely sure about oid, which has some characteristics of a user-data column. (OTOH, maybe we could allow just oid to retain an explicit pg_attribute entry... could be messy though.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 6 Jul 2010 10:08 On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> At one time I was hoping to get rid of explicit entries in pg_attribute >>> for system columns, which would negate this concern. �I think we're >>> stuck with them now, though, because of per-column permissions. > >> Because someone might want to grant per-column permissions on those >> columns? �That seems like an awfully thin reason to keep all that >> bloat around. �I bet the number of people who have granted per-column >> permissions on, say, cmax can be counted on one hand - possibly with >> five fingers left over. > > I'd agree with that argument for the most part, but I'm not entirely > sure about oid, which has some characteristics of a user-data column. > > (OTOH, maybe we could allow just oid to retain an explicit pg_attribute > entry... could be messy though.) [woops, forgot to reply on-list] Treating OID as a user-defined column seems reasonable, and probably not even that messy if we put some appropriate macros in place. I'm guessing the messy part would be finding all the places that expect to be consulting a real pg_attribute row and supplying them with a faked-up one in its place. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 6 Jul 2010 14:49
Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010: > Treating OID as a user-defined column seems reasonable, and probably > not even that messy if we put some appropriate macros in place. I'm > guessing the messy part would be finding all the places that expect to > be consulting a real pg_attribute row and supplying them with a > faked-up one in its place. Agreed. I'm intending to work on logical column identifiers for 9.1. Perhaps I could try to have a look at this, too, while at it. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |