Обсуждение: "ALSO" keyword to "CREATE RULE" patch
Dear patchers,
Please find attached a small patch to add an optionnal "ALSO" keyword
to the "CREATE RULE" syntax.
The "ALSO" keyword can be used where "INSTEAD" would be used,
to mean the opposite, i.e. the current default behavior of rules
which adds operations to the current one. IMHO, it makes the
intended behavior much clearer for the basic user (say, me;-).
CREATE RULE some_table_del AS
ON DELETE TO some_table DO ALSO
(
DELETE FROM this_other_table WHERE id=old.id;
);
Of course, the absence of the "ALSO" keyword preserves the previous
behavior... that is it behaves the same as with the "ALSO" keyword.
This patch was made against 7.4.1 with the "difforig" script
provided by postgresql.
It adds "ALSO" keyword in the parser code (two lines), fixes somehow the
documentation and sql help, and modifies four of the "RULE"
test cases to use this keyword instead of the default nothing-ness.
It validated for me with a "make check".
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr
Вложения
Is ALSO part of the SQL standard? I can't imagine it is because there is no rule mention. I guess if were were coding from scratch, we could make the syntax INSTEAD or ALSO, but at this point, I don't see adding ALSO as a useful change. --------------------------------------------------------------------------- Fabien COELHO wrote: > > Dear patchers, > > Please find attached a small patch to add an optionnal "ALSO" keyword > to the "CREATE RULE" syntax. > > The "ALSO" keyword can be used where "INSTEAD" would be used, > to mean the opposite, i.e. the current default behavior of rules > which adds operations to the current one. IMHO, it makes the > intended behavior much clearer for the basic user (say, me;-). > > CREATE RULE some_table_del AS > ON DELETE TO some_table DO ALSO > ( > DELETE FROM this_other_table WHERE id=old.id; > ); > > Of course, the absence of the "ALSO" keyword preserves the previous > behavior... that is it behaves the same as with the "ALSO" keyword. > > This patch was made against 7.4.1 with the "difforig" script > provided by postgresql. > > It adds "ALSO" keyword in the parser code (two lines), fixes somehow the > documentation and sql help, and modifies four of the "RULE" > test cases to use this keyword instead of the default nothing-ness. > > It validated for me with a "make check". > > Have a nice day, > > -- > Fabien Coelho - coelho@cri.ensmp.fr Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend -- 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
Dear Bruce, > Is ALSO part of the SQL standard? I can't imagine it is because there > is no rule mention. As RULE is not in the SQL standard, ALSO is sure no part of it. > I guess if we were coding from scratch, we could make the syntax INSTEAD > or ALSO, but at this point, I don't see adding ALSO as a useful change. It depends on what you mean by "useful". It is certainly non essential. I just think it is "user-friendly". It took me some time to understand that rules were appended by default. With the "ALSO" keyword it would have been instantaneous. When I first looked at the syntax with the "INSTEAD" which is optionnal and without alternative, I thought that it was one of those useless keywords that are allowed so as to make SQL more English-like, as the "COLUMN" keyword in the ALTER TABLE syntax. You may argue that I did not read the documentation in depth, but I'm not sure I'm the only one;-) The change is very small (2 lines added, 2 lines changed), and upward compatible, provided that the user has not used ALSO as an object name, what seems rather unlikely IMVVHO. Most of the patch deals with the documentation, which is rather ugly because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there is no name for the default behavior. I think "ALSO" fixes this issue as it clarifies the explanations. Have a nice day, -- Fabien.
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Most of the patch deals with the documentation, which is rather ugly
> because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there
> is no name for the default behavior. I think "ALSO" fixes this issue as it
> clarifies the explanations.
Hmm ... I find that argument much more convincing than any of the others
...
Jan, what do you think? You invented this command's syntax IIRC.
regards, tom lane
Tom Lane wrote: > Fabien COELHO <coelho@cri.ensmp.fr> writes: > > Most of the patch deals with the documentation, which is rather ugly > > because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there > > is no name for the default behavior. I think "ALSO" fixes this issue as it > > clarifies the explanations. > > Hmm ... I find that argument much more convincing than any of the others > ... > > Jan, what do you think? You invented this command's syntax IIRC. I thought the syntax came from Berkeley. We can add ALSO if folks like it. I can't think of cases where we have keywords for both on and off behavior, and allow a default if the keyword is missing. -- 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
> I thought the syntax came from Berkeley. We can add ALSO if folks like > it. I can't think of cases where we have keywords for both on and off > behavior, and allow a default if the keyword is missing. ALTER TABLE ... DROP CONSTRAINT ... [ RESTRICT | CASCADE ] ; CREATE TABLE ... [ WITH OIDS | WITHOUT OIDS ] ... ; CREATE USER ... [ CREATEDB | NOCREATEDB ] ... ; IMHO, from the language design point of view, it seems better if all options have a name. -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien COELHO wrote: > > > I thought the syntax came from Berkeley. We can add ALSO if folks like > > it. I can't think of cases where we have keywords for both on and off > > behavior, and allow a default if the keyword is missing. > > ALTER TABLE ... DROP CONSTRAINT ... [ RESTRICT | CASCADE ] ; > > CREATE TABLE ... [ WITH OIDS | WITHOUT OIDS ] ... ; > > CREATE USER ... [ CREATEDB | NOCREATEDB ] ... ; > > IMHO, from the language design point of view, it seems better if all > options have a name. Makes sense to me now. No one liked the non-INSTEAD rule description, for sure. Shoot me the patch again and I will put in the the queue. Thanks. -- 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
> Shoot me the patch again and I will put in the the queue. Thanks. Please find attached (again) the patch I sent. It is against 7.4.1. If necessary, I can redo the job against current head. Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Вложения
Tom Lane wrote: > Fabien COELHO <coelho@cri.ensmp.fr> writes: >> Most of the patch deals with the documentation, which is rather ugly >> because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there >> is no name for the default behavior. I think "ALSO" fixes this issue as it >> clarifies the explanations. > > Hmm ... I find that argument much more convincing than any of the others > ... > > Jan, what do you think? You invented this command's syntax IIRC. I did not. We inherited it from Postgres 4.2. If people think an ALSO keyword will clearify things, what about renaming the whole CREATE RULE into something along the line CREATE QUERY REWRITE MACRO? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > Tom Lane wrote: > > > Fabien COELHO <coelho@cri.ensmp.fr> writes: > >> Most of the patch deals with the documentation, which is rather ugly > >> because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there > >> is no name for the default behavior. I think "ALSO" fixes this issue as it > >> clarifies the explanations. > > > > Hmm ... I find that argument much more convincing than any of the others > > ... > > > > Jan, what do you think? You invented this command's syntax IIRC. > > I did not. We inherited it from Postgres 4.2. If people think an ALSO > keyword will clearify things, what about renaming the whole CREATE RULE > into something along the line CREATE QUERY REWRITE MACRO? Are you saying you don't want ALSO added? -- 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
Bruce Momjian wrote: > Jan Wieck wrote: >> Tom Lane wrote: >> >> > Fabien COELHO <coelho@cri.ensmp.fr> writes: >> >> Most of the patch deals with the documentation, which is rather ugly >> >> because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there >> >> is no name for the default behavior. I think "ALSO" fixes this issue as it >> >> clarifies the explanations. >> > >> > Hmm ... I find that argument much more convincing than any of the others >> > ... >> > >> > Jan, what do you think? You invented this command's syntax IIRC. >> >> I did not. We inherited it from Postgres 4.2. If people think an ALSO >> keyword will clearify things, what about renaming the whole CREATE RULE >> into something along the line CREATE QUERY REWRITE MACRO? > > Are you saying you don't want ALSO added? > No, I am saying that CREATE RULE is so often misinterpreted to work like a trigger and when we explain that it is more like Macro expansion before the query is executed they understand better. CREATE RULE itself is just vague, with or without ALSO. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > Bruce Momjian wrote: > > > Jan Wieck wrote: > >> Tom Lane wrote: > >> > >> > Fabien COELHO <coelho@cri.ensmp.fr> writes: > >> >> Most of the patch deals with the documentation, which is rather ugly > >> >> because it keeps telling about "INSTEAD" vs "non-INSTEAD" rules, as there > >> >> is no name for the default behavior. I think "ALSO" fixes this issue as it > >> >> clarifies the explanations. > >> > > >> > Hmm ... I find that argument much more convincing than any of the others > >> > ... > >> > > >> > Jan, what do you think? You invented this command's syntax IIRC. > >> > >> I did not. We inherited it from Postgres 4.2. If people think an ALSO > >> keyword will clearify things, what about renaming the whole CREATE RULE > >> into something along the line CREATE QUERY REWRITE MACRO? > > > > Are you saying you don't want ALSO added? > > > > No, I am saying that CREATE RULE is so often misinterpreted to work like > a trigger and when we explain that it is more like Macro expansion > before the query is executed they understand better. CREATE RULE itself > is just vague, with or without ALSO. True. -- 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
Patch applied. Thanks. --------------------------------------------------------------------------- Fabien COELHO wrote: > > > Shoot me the patch again and I will put in the the queue. Thanks. > > Please find attached (again) the patch I sent. It is against 7.4.1. > If necessary, I can redo the job against current head. > > Have a nice day, > > -- > Fabien Coelho - coelho@cri.ensmp.fr Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- 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
> I thought the syntax came from Berkeley. We can add ALSO if folks like > it. I can't think of cases where we have keywords for both on and off > behavior, and allow a default if the keyword is missing. ALTER TABLE ... DROP CONSTRAINT ... [ RESTRICT | CASCADE ] CREATE TABLE ... [ WITH OIDS | WITHOUT OIDS ] CREATE USER [ CREATEDB | NOCREATEDB ] ... IMHO, from the language design point of view, it seems better if all options have a name. -- Fabien.