diff options
author | Marc G. Fournier <scrappy@hub.org> | 1996-10-04 20:38:49 +0000 |
---|---|---|
committer | Marc G. Fournier <scrappy@hub.org> | 1996-10-04 20:38:49 +0000 |
commit | bf3473c468b1938f782fdcc208bd62c4b061daa3 (patch) | |
tree | 06ee5cbd2cad4cf0dee22ec1884bb4ecf84eb135 /src/backend/commands/copy.c | |
parent | cbb3edc7e57d685a4b67f929002e2ac629755aad (diff) | |
download | postgresql-PG95-1_08.tar.gz postgresql-PG95-1_08.zip |
Oops, wrong message with the other patch...this was the patch for the otherPG95-1_08
comment, so here is the comment for the other patch *grin*
> > You are right. I checked the gramar and saw the ability to use the
> > parameter. I looked at the manual pages, and saw no reference to it. I
> > tried running it, and found vacuum does nothing when you give it a table
> > name.
> >
> > I checked a debug version of postgres, and the table name is passed to
> > vacuum() in the variable (char *vacrel). The problem is that the vacuum
> > spans transactions, and the vacrel name gets changed to '<vacuum>',
> > which is the name of the portal that gets created in
> > vacuum.c::_vc_vacuum(). vacuum.c::_vc_init() does a
> > CommitTransactionCommand() which frees the memory allocated to vacrel.
> >
> > Should I change vacuum.c to copy the relation name to a local string
> > variable of vacuum(), or do you recommend we allocate the table name in
> > a different fashion? You are the man who knows the most about this.
>
> static NameData VacRel;
Done. Attached is the patch. I have already applied it to the 2.0
tree. (Marc!)
I tested it and it works. I also applied documentation patches to go
with it.
So now vacuum can be run for only one table if you wish.
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
Diffstat (limited to 'src/backend/commands/copy.c')
0 files changed, 0 insertions, 0 deletions