Robert Treat <[EMAIL PROTECTED]> writes:
> Seems merging the two would work... attlogpos, the attributes
> logical position.
Unless anyone has any further objections, I'll switch to using attlogpos.
-Neil
---(end of broadcast)---
TIP 2: you can ge
Tom Lane wrote:
If the ALTER is changing the column type, it's not really the same
column anymore;
This doesn't strike. "If the ALTER is changing the number of columns,
it's not really the same table anymore" is as true as your statement.
Still, pg_class.oid remains the same for ADD and DROP col
Andreas Pflug <[EMAIL PROTECTED]> writes:
> To put it differently: a ALTER COLUMN command may never-ever change the
> identifier of the column, i.e. attrelid/attnum.
If the ALTER is changing the column type, it's not really the same
column anymore; I see nothing wrong with assigning a new attnum
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Maybe my proposal wasn't clear enough:
Just as an index references a pg_class entry by it's OID, not some value
identifying it's physical storage, all objects might continue
referencing columns by attnum.
That's exactly the same t
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Maybe my proposal wasn't clear enough:
> Just as an index references a pg_class entry by it's OID, not some value
> identifying it's physical storage, all objects might continue
> referencing columns by attnum.
That's exactly the same thing I am saying
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I don't quite understand your argumentation.
My point is that to change attnum into a logical position without
breaking client apps (which is the ostensible reason for doing it
that way), we would need to redefine all system catalog
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I don't quite understand your argumentation.
My point is that to change attnum into a logical position without
breaking client apps (which is the ostensible reason for doing it
that way), we would need to redefine all system catalog entries that
referenc
On Thu, 2003-11-20 at 23:27, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Actually, I deliberately chose attpos rather than attlognum (which is
> > what some people had been calling this feature earlier). My reasoning
> > was that the "logical number" is really a nonsensical idea:
Tom Lane wrote:
It's completely fallacious to imagine that we could make this change be
transparent to external applications. To take two examples:
1. How many places do you think know that pg_attribute.attnum links to
pg_attrdef.adnum? pg_dump, psql, and the JDBC driver all appear to
know that,
> I don't have a better choice of name offhand, but if we spend 1% of the
> time already spent arguing about these issues on finding a better name,
> I'm sure we can think of one ;-)
virtual (attvirtnum)
external (attextnum)
atttisoywnum -> attribute this is the one you want number
---
Neil Conway <[EMAIL PROTECTED]> writes:
> Actually, I deliberately chose attpos rather than attlognum (which is
> what some people had been calling this feature earlier). My reasoning
> was that the "logical number" is really a nonsensical idea: we just
> invented it on the spot.
True ...
> In co
Tom Lane <[EMAIL PROTECTED]> writes:
> "attpos" is a horrid choice of name, because no one will be able to
> remember which of "attnum" and "attpos" is which. Pick a more
> distinct name. Offhand the best thing I can think of is "attlognum"
> or "attlogpos".
Actually, I deliberately chose attpos
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
>> BTW, one main consideration is that all the postgres admin apps will now
>> need to support ORDER BY attlognum for 7.5+.
> Yeah... how about maintaining attnum for the logical attribute number
Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
> On Thu, Nov 20, 2003 at 10:39:24AM -0500, Tom Lane wrote:
> (c) Do I need to consider inheritance?
>>
>> Yes. I think it'd be good if things were constrained so that columns
>> 1..n in a parent table always matched columns 1..n in every child,
>>
On Thu, Nov 20, 2003 at 10:39:24AM -0500, Tom Lane wrote:
> > (c) Do I need to consider inheritance?
>
> Yes. I think it'd be good if things were constrained so that columns
> 1..n in a parent table always matched columns 1..n in every child,
> which is not true now after adding/dropping colum
Neil Conway <[EMAIL PROTECTED]> writes:
> At present, attnum basically does three things: identifies an column
> within a relation, indicates which columns are system columns, and
> defines the order of a relation's columns. I'd like to move this last
> functionality into a separate pg_attribute co
On Wed, 19 Nov 2003 19:07:23 +0100, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
>is there
>any DB system out there that allows to reshuffle the column ordering?
Firebird:
ALTER TABLE tname ALTER COLUMN cname POSITION 7;
Servus
Manfred
---(end of broadcast)-
Why should ALTER COLUMN change the column number, i.e. position?
Because it creates a NEW column.
It may be that programmers should not rely on this, but it happens,
and in very
large projects. If we can avoid unexpected side-affects like moving the
columns position, then I think we should.
T
Andreas Pflug kirjutas K, 19.11.2003 kell 20:45:
> Dave Cramer wrote:
> >>Why should ALTER COLUMN change the column number, i.e. position?
> >
> >Rod's current proposed patch does that if you do an alter column alter
> >type. This is an artifact of the underlying mechanism. (ren old col, add
> >new
Dave Cramer wrote:
Andreas,
On Wed, 2003-11-19 at 13:07, Andreas Pflug wrote:
Dave Cramer wrote:
Andreas,
The point of this is to maintain the column position. I don't think that
an alter of a column type should move the column position.
Why should ALTER COLUMN change the column
Andreas,
On Wed, 2003-11-19 at 13:07, Andreas Pflug wrote:
> Dave Cramer wrote:
>
> >Andreas,
> >
> >The point of this is to maintain the column position. I don't think that
> >an alter of a column type should move the column position.
> >
> Why should ALTER COLUMN change the column number, i.e.
Dave Cramer wrote:
Andreas,
The point of this is to maintain the column position. I don't think that
an alter of a column type should move the column position.
Why should ALTER COLUMN change the column number, i.e. position?
It may be that programmers should not rely on this, but it happens, and
Andreas,
The point of this is to maintain the column position. I don't think that
an alter of a column type should move the column position. It may be
that programmers should not rely on this, but it happens, and in very
large projects. If we can avoid unexpected side-affects like moving the
colum
Christopher Kings-Lynne wrote:
Will adding the logical attribute number break all of the external
tools? pg_dump, etc are all dependent on attnum now?
Would it be possible to keep the meaning of attnum the same externally
and add another column internally to represent the physical number?
Inter
Will adding the logical attribute number break all of the external
tools? pg_dump, etc are all dependent on attnum now?
Would it be possible to keep the meaning of attnum the same externally
and add another column internally to represent the physical number?
Interesting idea. It would require a
Dave Cramer wrote:
> Will adding the logical attribute number break all of the external
> tools? pg_dump, etc are all dependent on attnum now?
>
> Would it be possible to keep the meaning of attnum the same externally
> and add another column internally to represent the physical number?
Interesti
Will adding the logical attribute number break all of the external
tools? pg_dump, etc are all dependent on attnum now?
Would it be possible to keep the meaning of attnum the same externally
and add another column internally to represent the physical number?
Dave
---(end
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>
> > BTW, one main consideration is that all the postgres admin apps will now
> > need to support ORDER BY attlognum for 7.5+.
>
> But that is only really important if they've also used the ALTER TABLE
> RESHUFFLE COL
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
need to do another. That seems fai
Christopher Kings-Lynne writes:
> BTW, one main consideration is that all the postgres admin apps will now
> need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
> > Right -- AFAICS, the only change in COPY compatibility would be if you
> > COPY TO'd a table and then changed the logical column order in some
> > fashion, you would no longer be able to restore the dump (unless you
> > specified a col
Neil Conway wrote:
> I'd like to add a new column to pg_attribute that specifies the
> attribute's "logical position" within its relation. The idea here is
> to separate the logical order of the columns in a relation from the
> on-disk storage of the relation's tuples. This allows us to easily &
>
Neil Conway wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I don't think you can speak of "bloat" for pg_attribute. But you
> > can speak of a problem when you want to do the old col = col + 1 in
> > the presence of a unique index.
>
> I'm sorry, but I'm not sure what either of these c
Right -- AFAICS, the only change in COPY compatibility would be if you
COPY TO'd a table and then changed the logical column order in some
fashion, you would no longer be able to restore the dump (unless you
specified a column list for the COPY FROM -- which, btw, pg_dump
does). I don't think it wi
Jon Jensen <[EMAIL PROTECTED]> writes:
> You're just saying it'd break old dumps, right? I'd assume COPY FROM
> would use attpos ordering when writing out columns, or that every
> user-visible interaction with the table pretends the columns are in
> attpos order. So dumps would break no more or les
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't think you can speak of "bloat" for pg_attribute. But you
> can speak of a problem when you want to do the old col = col + 1 in
> the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean -- can
you elabora
On Mon, 17 Nov 2003, Neil Conway wrote:
> I'd like to add a new column to pg_attribute that specifies the
> attribute's "logical position" within its relation. The idea here is
> to separate the logical order of the columns in a relation from the
> on-disk storage of the relation's tuples. This al
Neil Conway writes:
> (b) Using the above scheme that attnum == attpos initially, there
> won't be any gaps in the sequence of attpos values. That means
> that if, for example, we want to move the column in position 50
> to position 1, we'll need to change the position's of all
I'd like to add a new column to pg_attribute that specifies the
attribute's "logical position" within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily &
quickly change column order,
I'd like to add a new column to pg_attribute that specifies the
attribute's "logical position" within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily &
quickly change column order,
40 matches
Mail list logo
