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 get
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
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: we just
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
reference
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:
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:
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
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 in
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
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
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 column
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 columns.
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,
which is
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
and
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 rather than
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 contrast,
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
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?
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
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,
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. position?
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 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 col,
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.
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
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?
Interesting
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
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,
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
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 allows
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 elaborate?
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 less
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
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 comments mean
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
quickly
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 column
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
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
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 COLUMNS
40 matches
Mail list logo
