Darren Duncan dar...@darrenduncan.net writes:
That's a really old post/thread, and I'm not arguing for any kind of action
related to RULEs, please disregard the message. -- Darren Duncan
Oh, my fault --- for some reason my mail reader popped it up as an unread
message, and I failed to notice
Darren Duncan dar...@darrenduncan.net writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we might begin to tell people
they can't use
On 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net writes:
I have a proposal.
Assuming we decide to do away with RULEs,
You lost me already.
If we had replacement functionality for everything that can be done with
rules, we could start to think about when we
Robert Haas robertmh...@gmail.com writes:
The problems with MERGE are mostly around concurrency, as far as I can
tell. I can't see why RULEs would have anything to do with it -
except that I don't see how MERGE can sanely support rules, and even
if we find a way to make it do that, anyone
On Mon, Oct 22, 2012 at 8:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The problems with MERGE are mostly around concurrency, as far as I can
tell. I can't see why RULEs would have anything to do with it -
except that I don't see how MERGE can sanely
[I'm replying to Robert's message only because it is the latest on
the thread; I'm actually kinda replying to the whole thread in
general.]
When catching up on a backlog, one would hope that any thread
comprising more than 5% of said backlog would be more constructive.
:-(
As someone coming in
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
this is a *very* rough measure, but it still tends to indicate to me
: [HACKERS] Deprecating RULES
Good point on the CTE (and it's correct). I think by any reasonable
definition
rules are in fact already de facto deprecated: they are not being extended
to
interact with other features and the community is advising against their
use.
I don't think anybody would
On 10/18/2012 09:10 PM, Josh Berkus wrote:
Daniel,
I'm not going to disagree with that, I only feel it's reasonable to
ask why those who react so strongly against deprecation why they think
what they do, and receive a clinical response, because not everyone
has seen those use cases. My level
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
this is a *very* rough measure, but it still tends to indicate to me that
the maintenance burden isn't terribly high.
That's a pretty neat
That's a pretty neat one-liner. However... in my view, the real cost
of rules is that they are hard to support as we add new features to
SQL. I believe we already decided to punt on making them work with
CTEs... and maybe one other case? I don't really remember the details
any more, but
On 19 October 2012 22:03, Josh Berkus j...@agliodbs.com wrote:
Unless the easiest way to implement MERGE is to extend RULEs.
FWIW, I'd say that's probably about the hardest possible way to
implement MERGE, assuming that we prioritise providing robust UPSERT
support, as I strongly feel we should.
On 10/17/2012 07:25 PM, Tom Lane wrote:
I'm fairly annoyed by the entire tenor of this conversation, because
the people who are hollering the loudest seem to be people who have
never actually touched any of the rules code, but nonetheless seem
prepared to tell those of us who have what to
On 10/17/2012 04:25 PM, Tom Lane wrote:
...Now having said that, I would definitely like to see rules in their
current form go away eventually. But not without a substitute.
Triggers are not a complete replacement, and no amount of wishful
thinking makes them so.
...
Perhaps it would be more
On Thu, Oct 18, 2012 at 6:46 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/17/2012 07:25 PM, Tom Lane wrote:
I'm fairly annoyed by the entire tenor of this conversation, because
the people who are hollering the loudest seem to be people who have
never actually touched any of the rules
On Wed, Oct 17, 2012 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
I would tend to say well, they're not hurting anyone, why not keep
them? Except that we're gathering an increasing number of features
(RETURNING, FDWs, CTEs, Command triggers) which don't
On 10/18/2012 01:11 PM, Daniel Farina wrote:
Here's another use case that in my history with RULES that didn't seem
to pan out so well: In my recollection, one way to use rules is to
retarget operations that happen against a view and move them to a
table, and as I recall to make this work as
Well, it'd be nice to be able to rewrite a query referring to a table
to still refer to that same table, but you can't, because you get
infinite recursion.
If that was possible it would be quite easy to express any row/column level
security policies with it.
If you could do that, it'd
On Thu, Oct 18, 2012 at 1:55 PM, Andrew Dunstan and...@dunslane.net wrote:
On 10/18/2012 01:11 PM, Daniel Farina wrote:
Here's another use case that in my history with RULES that didn't seem
to pan out so well: In my recollection, one way to use rules is to
retarget operations that happen
Daniel,
I'm not going to disagree with that, I only feel it's reasonable to
ask why those who react so strongly against deprecation why they think
what they do, and receive a clinical response, because not everyone
has seen those use cases. My level of interest in deprecation is only
as far
On Thu, Oct 18, 2012 at 6:10 PM, Josh Berkus j...@agliodbs.com wrote:
Daniel,
I'm not going to disagree with that, I only feel it's reasonable to
ask why those who react so strongly against deprecation why they think
what they do, and receive a clinical response, because not everyone
has
Peter Geoghegan pe...@2ndquadrant.com writes:
Clearly deprecating rules implies some loss of functionality - there
is no exact, drop-in equivalent to something that magically rewrites
SQL that isn't equally baroque and problematic. If that's the bar,
then detractors of rules should stop
On 12 October 2012 10:08, Daniel Farina dan...@heroku.com wrote:
On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
As regards cost/benefit analysis, this is a low importance feature,
but then that is why I proposed a low effort fix that is flexible to
the needs of
On 10/17/2012 02:48 AM, Simon Riggs wrote:
Would you or someone else be able to come up with some words of
caution for us to put in the manual that would be helpful to
developers?
There isn't even a list of caveats for rules.
I think we need the inverse. Some documentation on why to use
On 17 October 2012 18:02, Joshua D. Drake j...@commandprompt.com wrote:
Note: Do not use, use Triggers with Functions instead link
Agreed, something simple is required. I suggest expanding that just a little...
Rules are a non-SQL Standard feature and where possible we recommend
that you write
On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
Clearly deprecating rules implies some loss of functionality - there
is no exact, drop-in equivalent to something that magically rewrites
SQL that isn't equally baroque and problematic.
Maybe we can
All,
For the record, I like RULEs and would prefer if someone fixed the
issues with them instead of deprecating them. However, I also
acknowledge that that is unlikely to happen.
Would you or someone else be able to come up with some words of
caution for us to put in the manual that would be
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering why.
I would suggest something like
On 10/17/2012 01:02 PM, Joshua D. Drake wrote:
On 10/17/2012 02:48 AM, Simon Riggs wrote:
Would you or someone else be able to come up with some words of
caution for us to put in the manual that would be helpful to
developers?
There isn't even a list of caveats for rules.
I think we need
On 10/12/12, Josh Berkus j...@agliodbs.com wrote:
I realize you weren't around when we removed row OIDs, but I was *still*
getting flack from that in 2008. And we lost entire OSS projects to
other databases because of removing row OIDs. And those were marked
deprecated for 3 years before we
On 17 October 2012 18:50, Andrew Dunstan and...@dunslane.net wrote:
I don't know how many times I have to say this: people are not listening.
Tom has already given a case for it upthread:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk operations, a
On 17 October 2012 18:46, Greg Stark st...@mit.edu wrote:
I would suggest something like
Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
Greg,
Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
desired result. There are also unexpected interactions with other
components when
Greg Stark st...@mit.edu writes:
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering why.
On 10/17/2012 10:46 AM, Greg Stark wrote:
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering
I am not sure where to stick it but we should also include the fact that
rules are almost always slower that a trigger/function comparative.
That wouldn't be accurate, actually.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On 10/17/12 2:31 AM, Dimitri Fontaine wrote:
Then if you insist on comparing to a macro facility, as we're talking
about dynamic code rewriting, maybe we need to compare RULEs to the lisp
style macro facility, which is nothing like a pre-processor facility (in
lisp, that's the reader, I think).
On 17 October 2012 18:46, Greg Stark st...@mit.edu wrote:
I would suggest something like
Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
On 10/17/12 10:46 AM, Greg Stark wrote:
Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
desired result. There are also unexpected interactions
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk operations, a rule could greatly outperform
a trigger. It's difficult to walk away from that - unless somebody
can prove that
On 10/17/2012 11:32 AM, Josh Berkus wrote:
I am not sure where to stick it but we should also include the fact that
rules are almost always slower that a trigger/function comparative.
That wouldn't be accurate, actually.
Let me add: when used with partitioning. I should have been more
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk operations, a rule could greatly outperform
a trigger. It's difficult to walk away
On Wed, Oct 17, 2012 at 12:43 PM, Andrew Dunstan and...@dunslane.net wrote:
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk
You and Josh seem to be strong proponents of rules for reasons other
than I just don't want to break applications. That's not too many
to ask both of you: can you itemize your use cases and how important
you feel they are?
Well, my main issue is actually that I don't want to break people's
On 10/17/12 12:57 PM, Daniel Farina wrote:
I'll have to register my disagreement then, in the special case where
a feature becomes so obscure that many people don't have a wide-spread
intuition at what it's good at or used for. Tom also said build the
replacement, and without itemization of
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/17/12 12:57 PM, Daniel Farina wrote:
I'll have to register my disagreement then, in the special case where
a feature becomes so obscure that many people don't have a wide-spread
intuition at what it's good at or used
On Wed, Oct 17, 2012 at 5:45 PM, Daniel Farina dan...@heroku.com wrote:
retort -- which is true, Heroku's user base is not provably
representative of all users. But what else is there to go on, besides
experiences of others, such as yours and Andrew's, or others?
Well, Heroku doesn't support
Daniel,
Unfortunately I myself see little evidence of the vast, vast --
several nines of vast -- majority of folks using rules, and as I said:
as a thought experiment, merely one solved bug is worth more to me
than rules from what I know at this time.
Again, the answer to this is to run an
On 17 October 2012 23:24, Josh Berkus j...@agliodbs.com wrote:
I fact, I'll go further and say that I believe we will be deprecating
RULEs eventually. It's merely a question of how long that will take and
what we need to document, announce and implement before then.
I would tend to say
On Wed, Oct 17, 2012 at 3:24 PM, Josh Berkus j...@agliodbs.com wrote:
Daniel,
Unfortunately I myself see little evidence of the vast, vast --
several nines of vast -- majority of folks using rules, and as I said:
as a thought experiment, merely one solved bug is worth more to me
than rules
Josh Berkus j...@agliodbs.com writes:
I would tend to say well, they're not hurting anyone, why not keep
them? Except that we're gathering an increasing number of features
(RETURNING, FDWs, CTEs, Command triggers) which don't work well together
with RULEs.
Really? On what do you base that
On Oct 17, 2012, at 4:45 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/17/12 12:57 PM, Daniel Farina wrote:
I'll have to register my disagreement then, in the special case where
a feature becomes so obscure that many people don't have a
On 15 October 2012 00:30, Greg Stark st...@mit.edu wrote:
On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to the first person that can prove me wrong.
Being written as
On 15 October 2012 11:41, Greg Stark st...@mit.edu wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to
On 15 October 2012 11:41, Greg Stark st...@mit.edu wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to
On Monday, October 15, 2012 03:07:21 PM Simon Riggs wrote:
On 15 October 2012 11:41, Greg Stark st...@mit.edu wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not
On 15 October 2012 00:30, Greg Stark st...@mit.edu wrote:
In fact it's not a very good analogy because the situation is
*precisely* the same -- rules *are* macros and manipulate the raw sql
before it's run and the reason they can't be replaced by triggers is
because, like functions, triggers
On 10/15/2012 09:07 AM, Simon Riggs wrote:
On 15 October 2012 11:41, Greg Stark st...@mit.edu wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a
On 15 October 2012 14:43, Andrew Dunstan and...@dunslane.net wrote:
On 10/15/2012 09:07 AM, Simon Riggs wrote:
On 15 October 2012 11:41, Greg Stark st...@mit.edu wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Please can anyone show me the SQL for a rule
On 10/15/2012 12:41 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a view or a trigger? I do not believe such a thing exists and I will
provide free beer to the first person
Simon, Peter, etc.:
Perhaps we should take a different tack on this discussion: what feature
development is the continued presense of RULES currently blocking? If
the rest of us had some idea why you considered this deprecation urgent,
it would help!
--
Josh Berkus
PostgreSQL Experts Inc.
On Mon, Oct 15, 2012 at 12:30:56AM +0100, Greg Stark wrote:
On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be
On 15 October 2012 18:43, Josh Berkus j...@agliodbs.com wrote:
Perhaps we should take a different tack on this discussion: what feature
development is the continued presense of RULES currently blocking? If
the rest of us had some idea why you considered this deprecation urgent,
it would
On Mon, Oct 15, 2012 at 02:14:34PM +0100, Peter Geoghegan wrote:
On 15 October 2012 00:30, Greg Stark st...@mit.edu wrote:
In fact it's not a very good analogy because the situation is
*precisely* the same -- rules *are* macros and manipulate the raw sql
before it's run and the reason they
On 10/15/2012 03:23 PM, Bruce Momjian wrote:
I have trouble seeing how we could implement Postgres as efficiently
without C macros, but maybe that is the point --- efficiency is not
critical in SQL --- Java and C++ give other options that are good
enough and less error-prone.
Er, C++ uses
On Mon, Oct 15, 2012 at 03:51:58PM -0400, Andrew Dunstan wrote:
On 10/15/2012 03:23 PM, Bruce Momjian wrote:
I have trouble seeing how we could implement Postgres as efficiently
without C macros, but maybe that is the point --- efficiency is not
critical in SQL --- Java and C++ give other
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a bizarre discussion. Firstly this isn't even close to true.
The whole source of people's
On 13 October 2012 21:15, Joshua Berkus j...@agliodbs.com wrote:
Simon,
I think its sad we can't even attempt a technical conversation
without
you making snide ad hominem attacks that aren't even close to being
true on a personal level, nor accurate in a technical sense.
I would prefer it
Simon Riggs si...@2ndquadrant.com writes:
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a bizarre discussion. Firstly this isn't even close
On Oct 14, 2012, at 12:35 PM, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a
On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 12 October 2012 19:48, Greg Stark st...@mit.edu wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a bizarre
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
You also mention that 3 years wasn't long enough for some people, but
I am unsure as to your point there. It might be that we should take
longer than 3 years to deprecate things, or that the same pain will be
felt however long we leave it. I
Simon,
I think its sad we can't even attempt a technical conversation
without
you making snide ad hominem attacks that aren't even close to being
true on a personal level, nor accurate in a technical sense.
I would prefer it if you actually addressed my substantive arguments, which, so
far,
On 11 October 2012 23:59, Josh Berkus j...@agliodbs.com wrote:
With the DDL trigger, we're able to do that faster. The idea is you
can still delete it if you need compatibility, so we get the message
across without an extra release and without an annoying GUC (etc).
You're seeing these
On 12 October 2012 01:52, Andrew Dunstan and...@dunslane.net wrote:
I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat
surprised at the willingness of some people to spring surprises on users.
I've never caused nor argued in favour of hardcoded changes that catch users.
On 12 October 2012 00:45, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 11 October 2012 20:28, Simon Riggs si...@2ndquadrant.com wrote:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
What
;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Deprecating RULES
On 10/11/2012 08:20 PM, Daniel Farina wrote:
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could
On 10/12/2012 08:47 AM, Simon Riggs wrote:
On 12 October 2012 01:52, Andrew Dunstan and...@dunslane.net wrote:
I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat
surprised at the willingness of some people to spring surprises on users.
I've never caused nor argued in
On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
As regards cost/benefit analysis, this is a low importance feature,
but then that is why I proposed a low effort fix that is flexible to
the needs of users affected.
Is there any feature that is more loathed and more
On Friday, October 12, 2012 01:45:56 AM Peter Geoghegan wrote:
On 11 October 2012 20:28, Simon Riggs si...@2ndquadrant.com wrote:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
What exactly
On Thu, Oct 11, 2012 at 05:20:14PM -0700, Daniel Farina wrote:
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it
I don't think you're listening, none of those things are problems and
so not user hostile.
Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile? Wow, you must
have a very understanding group of users.
Lemme try to make it
On 10/12/2012 06:59 PM, Josh Berkus wrote:
I don't think you're listening, none of those things are problems and
so not user hostile.
Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile? Wow, you must
have a very
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a bizarre discussion. Firstly this isn't even close to true.
The whole source of people's discontentment is that triggers are *not*
equivalent to rules. If
Josh Berkus wrote:
I don't think you're listening, none of those things are problems and
so not user hostile.
Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile? Wow, you must
have a very understanding group of users.
On 10/12/12 11:57 AM, Darren Duncan wrote:
Assuming we decide to do away with RULEs, change the *documentation* for
RULEs right away in all supported maintenance branches (including 9.2),
saying that RULEs will be deprecated, but don't change any code / add
any warnings until 9.3.
I'd say
On Thu, Oct 11, 2012 at 8:52 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat
surprised at the willingness of some people to spring surprises on users. I
still come across uses of rules in the wild, and not just for
On 10/12/2012 08:48 PM, Greg Stark wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
This is a bizarre discussion. Firstly this isn't even close to true.
The whole source of people's discontentment is
On 12 October 2012 17:59, Josh Berkus j...@agliodbs.com wrote:
I don't think you're listening, none of those things are problems and
so not user hostile.
Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile? Wow, you must
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more difficult.
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Anybody that
Simon Riggs si...@2ndquadrant.com writes:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that
Tom Lane t...@sss.pgh.pa.us writes:
This is utter nonsense. We can't deprecate them until we have a
substitute that is better. If you want to get rid of rules, build the
replacement; don't just try to be a pain in the ass to users.
My understanding is that the main reason why RULEs are bad™
On 11 October 2012 20:50, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more
difficult.
For 9.3, I suggest we create a DDL trigger by
On Thu, Oct 11, 2012 at 6:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
Anyway, lets start with a discussion of what rules give us that SQL
standard features do not?
The somewhat broader question that this elicits is How would we go
about deprecating a feature that seems to be troublesome? I
On 11 October 2012 23:28, Josh Berkus j...@agliodbs.com wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that
On Thu, Oct 11, 2012 at 3:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 11 October 2012 23:28, Josh Berkus j...@agliodbs.com wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that RULES will be going away RSN.
2. In 9.4, send a warning every
With the DDL trigger, we're able to do that faster. The idea is you
can still delete it if you need compatibility, so we get the message
across without an extra release and without an annoying GUC (etc).
You're seeing these things as bugs. I see them as features. And we
don't need a GUC if
On Thu, Oct 11, 2012 at 3:59 PM, Josh Berkus j...@agliodbs.com wrote:
With the DDL trigger, we're able to do that faster. The idea is you
can still delete it if you need compatibility, so we get the message
across without an extra release and without an annoying GUC (etc).
You're seeing
1 - 100 of 108 matches
Mail list logo
