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
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
> 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 thi
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_attr
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
>
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
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
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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
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_fc
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 a
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 --- j
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, obvi
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
> 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 a
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
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 h
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 deci
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
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, obvi
> 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 a
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 s
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
> 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.
I kind of agree
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
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.
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 ha
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 t
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 then. It had a big
>
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.
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 then. It had a big
advantage that initdb isn't needed. N
"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
> 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
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 type
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
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 no
> 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 se
I was originally planning to revise pg_aggregate along the same lines
as pg_proc and so forth: add an aggnamespace column and fix the search
code to be namespace-aware. But it seemed a tad annoying that standard
function lookups would thereby incur *two* namespace-aware searches:
one in pg_aggreg
38 matches
Mail list logo
