Thread added to TODO.detail/drop.
---
Christopher Kings-Lynne wrote:
Actually, what we need to do to reclaim space is to enable table
recreation without the column, now that we have relfilenode for file
renaming. It
Christopher Kings-Lynne wrote:
Also, it seems to me that at some point we are forced to break client
compatibility.
It's not a users' consensus at all. I'm suspicious if
DROP COLUMN is such a significant feature to break
client compatibility at our ease.
Either we add attisdropped field to
Updating pg_attribute per se is not so hard --- just store new copies of
all the rows for the table. However, propagating the changes into other
places could be quite painful (I'm thinking of column numbers in stored
constraints, rules, etc).
It seems to me that reducing the column to
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: 12 April 2002 03:54
To: Bruce Momjian
Cc: Hiroshi Inoue; Christopher Kings-Lynne;
[EMAIL PROTECTED]
Subject: Re: RFC: Restructuring pg_aggregate
Bruce Momjian [EMAIL PROTECTED] writes:
I think that is
Actually, what we need to do to reclaim space is to enable table
recreation without the column, now that we have relfilenode for file
renaming. It isn't hard to do, but no one has focused on it. I want to
focus on it, but have not had the time, obviously, and would be very
excited to
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Why shouldn't aggregate functions have entries in pg_proc? Then one
search would cover both possibilities, and we could eliminate some
duplicate code in the parser.
Furthermore, we could make the new function privileges apply to
Tom Lane writes:
I was slightly bemused to notice that your implementation of it for
regular functions tests the privilege at plan startup but doesn't
actually throw the error until the function is called. What's the
point of that? Seems like we might as well throw the error in
init_fcache
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Christopher Kings-Lynne wrote:
I think that is why Tom was suggesting making all the column values NULL
and removing the pg_attribute row for the column. With a NULL value, it
doesn't take up any room in the tuple, and with the pg_attribute
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The real problem here is the fact that there are now missing attnos in
pg_attribute. Either that's handled or we renumber the attnos - which is
also quite hard?
Updating pg_attribute per se is not so hard --- just store new copies of
all the
Christopher Kings-Lynne wrote:
Actually, what we need to do to reclaim space is to enable table
recreation without the column, now that we have relfilenode for file
renaming. It isn't hard to do, but no one has focused on it. I want to
focus on it, but have not had the time, obviously,
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The real problem here is the fact that there are now missing attnos in
pg_attribute. Either that's handled or we renumber the attnos - which is
also quite hard?
Updating pg_attribute per se is not so hard --- just store
Christopher Kings-Lynne wrote:
Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is
kinda useless - you may as well just use a view!!!
So how would this occur?:
1. Lock target table for writing (allow reads)
2. Begin a table scan on target table, writing
a new
Hiroshi Inoue wrote:
Christopher Kings-Lynne wrote:
Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is
kinda useless - you may as well just use a view!!!
So how would this occur?:
1. Lock target table for writing (allow reads)
2. Begin a table scan on
Bruce Momjian [EMAIL PROTECTED] writes:
I think that is why Tom was suggesting making all the column values NULL
and removing the pg_attribute row for the column.
That was not my suggestion.
With a NULL value, it
doesn't take up any room in the tuple, and with the pg_attribute column
gone,
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
That means that
a lot of low-level places *do* need to know about the dropped-column
convention, else they can't make any sense of tuple layouts.
Why ? As you already mentioned, there were not that many places
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
I think he made a representational mistake by trying to change the
attnums of dropped columns to be negative values.
Negative attnums had 2 advantages
Hiroshi Inoue wrote:
Why ? As you already mentioned, there were not that many places
to be changed.
Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system, and the advantages.
I already
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why ? As you already mentioned, there were not that many places
to be changed.
Well what's changed since then ?
Here is an old email from me that outlines the idea of having a
physical/logical attribute numbering system, and the
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only a waste of time.
Christopher Kings-Lynne wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only a
Christopher Kings-Lynne wrote:
Actually, what we need to do to reclaim space is to enable table
recreation without the column, now that we have relfilenode for file
renaming. It isn't hard to do, but no one has focused on it. I want to
focus on it, but have not had the time, obviously,
Christopher Kings-Lynne wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me seems only
Hiroshi Inoue wrote:
It seems to me that whatever we do
will require some kind of client breakage.
Physical/logical attnum approach was mainly to not break
clients. I implemented it on trial but the implementation
was hard to maintain unfortunately. It's pretty difficult
to decide
Bruce Momjian wrote:
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
What DROP COLUMN has brought me
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
If the client has to bear the some part, isn't the invisible
column approach much simpler ?
I've put a pretty much time into DROP COLUMN feature but
I am really disappointed to see the comments in this thread.
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
That means that
a lot of low-level places *do* need to know about the dropped-column
convention, else they can't make any sense of tuple layouts.
Why ? As you already mentioned, there were not that many places
to be changed.
There
That seems like pure speculation to me, if not outright wrong. If we
can't renumber the attnums it'll be because the table's tuples still
have data at a particular column position. Since we'll need to know
the datatype of that data (if only to skip over it correctly), there
will still have
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
You know there is a way to do this and not break client compatibility.
Rename the current pg_attribute relation to pg_baseatt or something. Fix
all references to it in the code. Create a system view called pg_attribute
which is SELECT *
A more serious objection is that this will break client applications
that know about the pg_aggregate table. However, 7.3 is already going
to force a lot of reprogramming of clients that inspect system tables,
because of the addition of namespaces. Restructuring pg_aggregate
doesn't seem
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
How about putting a note in the 7.3 release that tells them not to rely on
sequential attnums in tn pg_attribute anymore. That should make it easier
to implement column dropping in the future?
That seems like pure speculation to me, if not
Tom Lane writes:
Why shouldn't aggregate functions have entries in pg_proc? Then one
search would cover both possibilities, and we could eliminate some
duplicate code in the parser.
Furthermore, we could make the new function privileges apply to aggregates
as well.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Why shouldn't aggregate functions have entries in pg_proc?
Furthermore, we could make the new function privileges apply to aggregates
as well.
Good point. Another thing that would fall out for free is that the
aggregate
32 matches
Mail list logo
