SET WITHOUT CLUSTER patch
Hi,
I have done a patch for turning off clustering on a table entirely.
Unforunately, of the three syntaxes I can think of, all cause
shift/reduce errors:
SET WITHOUT CLUSTER;
DROP CLUSTER
CLUSTER ON NONE;
This is the new grammar that I added:
/* ALTER TABLE <name> SET WITHOUT CLUSTER */
| ALTER TABLE relation_expr SET WITHOUT CLUSTER
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n->subtype = 'L';
n->relation = $3;
n->name = NULL;
$$ = (Node *)n;
}
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)
Even changing the syntax to "qualified_name DROP CLUSTER" doesn't work
due to the existence of "relation_expr DROP ...".
What's the solution? I can't figure it out...
Chris
Attachments:
nocluster.txttext/plain; name=nocluster.txtDownload+89-65
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
This is the new grammar that I added:
| ALTER TABLE relation_expr SET WITHOUT CLUSTER
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)
Well, seems like what you have to do is leave it as relation_expr
as far as bison is concerned, but test in the C-code action and error
out if "*" was specified. (Accepting ONLY seems alright to me.)
You could possibly find a solution at the grammar level but it'd
probably be a much worse kluge ...
regards, tom lane
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)Well, seems like what you have to do is leave it as relation_expr
as far as bison is concerned, but test in the C-code action and error
out if "*" was specified. (Accepting ONLY seems alright to me.)
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Well, seems like what you have to do is leave it as relation_expr
as far as bison is concerned, but test in the C-code action and error
out if "*" was specified. (Accepting ONLY seems alright to me.)
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?
Seems like more work than it's really worth ... but if you wanna ...
regards, tom lane
Christopher Kings-Lynne wrote:
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)Well, seems like what you have to do is leave it as relation_expr
as far as bison is concerned, but test in the C-code action and error
out if "*" was specified. (Accepting ONLY seems alright to me.)Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?
I just thought about this. CLUSTER is more of a storage-level
specification, rather than a logical one. Seems it is OK that WITOUTH
CLUSTER not recurse into inherited tables, especially since the CLUSTER
command does not.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?I just thought about this. CLUSTER is more of a storage-level
specification, rather than a logical one. Seems it is OK that WITOUTH
CLUSTER not recurse into inherited tables, especially since the CLUSTER
command does not.
The patch I submitted earlier already does do recursion - I don't see
why it shouldn't really. It's better than failing saying that legal
grammar is in fact illegal :)
Chris
Christopher Kings-Lynne wrote:
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?I just thought about this. CLUSTER is more of a storage-level
specification, rather than a logical one. Seems it is OK that WITOUTH
CLUSTER not recurse into inherited tables, especially since the CLUSTER
command does not.The patch I submitted earlier already does do recursion - I don't see
why it shouldn't really. It's better than failing saying that legal
grammar is in fact illegal :)
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
Well, maybe - up to you.
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.Well, maybe - up to you.
Well, if we don't recurse on creation, does it make sense to recurse on
destruction? Seems it might surpise people. Do we have that asymetry
in any other area?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.Well, maybe - up to you.
Well, if we don't recurse on creation, does it make sense to recurse on
destruction? Seems it might surpise people. Do we have that asymetry
in any other area?
I'm not sure if it's assymetric. You can't recursively set the cluster
bit, because child tables may not have an equally named index. However
when you are unsetting the bit it doesn't matter how is the index named.
I'm not sure what side does this argument favor. I'd say ALTER
TABLE/WITHOUT CLUSTER shouldn't recurse but I don't feel strongly about
it.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Everybody understands Mickey Mouse. Few understand Hermann Hesse.
Hardly anybody understands Einstein. And nobody understands Emperor Norton."
Alvaro Herrera wrote:
On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.Well, maybe - up to you.
Well, if we don't recurse on creation, does it make sense to recurse on
destruction? Seems it might surpise people. Do we have that asymetry
in any other area?I'm not sure if it's assymetric. You can't recursively set the cluster
bit, because child tables may not have an equally named index. However
when you are unsetting the bit it doesn't matter how is the index named.
Right, we can recurse on WITHOUT and not using WITH, but would people
expect WITHOUT to recurse?
If we allowed indexes to span tables, it would be nice for both to
recurse, but because we don't, I think neither should.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073