On Wed, Jul 7, 2010 at 1:29 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010:
>> On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote:
>
>> > In any case, having a mutable logical column
>> > position is the feature that's been most requested.
>>
>
Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010:
> On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote:
> > In any case, having a mutable logical column
> > position is the feature that's been most requested.
>
> I think that's true. But the physical storage position woul
Robert Haas writes:
> On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote:
>> Why wouldn't it be feasible?
> Just because it might be too much to do all at once.
My thought is that the hardest part of this is going to be making sure
that every "column index" usage in the code is properly categ
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote:
>> I have a strong suspicion that's going to be a, ahem, challenging
>> project. But it would be great to have. Getting rid of the system
>> column entries from pg_attribute is probably easy by comparison.
>
> It will be a bit invasive, but I
Robert Haas wrote:
On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera
wrote:
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.
I have a strong suspicion that's going to be a, ahem, challenging
project. But it wo
On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera
wrote:
> 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 par
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 consult
On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane 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, th
Robert Haas writes:
> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane 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 som
On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 someth
11 matches
Mail list logo
