Darren Duncan 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 the date. My apologies
On 2013.08.27 7:57 PM, Tom Lane wrote:
Darren Duncan 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
t
Darren Duncan 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 rules. Unfortunately, we d
tgresql.org
> Subject: Re: [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
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas wrote:
> On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan 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
Kevin Grittner escribió:
> [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.]
Thanks for the great summary.
> (4) Subsequent discussion has produced a few shadowy hints at what
> such uses look like, with
[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 l
On Mon, Oct 22, 2012 at 8:57 AM, Tom Lane wrote:
> Robert Haas 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 fin
Robert Haas 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 already using RULEs w
On Fri, Oct 19, 2012 at 5:03 PM, Josh Berkus wrote:
>> 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
On 19 October 2012 22:03, Josh Berkus 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.
--
Peter Geogh
> 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, b
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan 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 one-liner. However.
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 Thu, Oct 18, 2012 at 6: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
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
On Thu, Oct 18, 2012 at 1:55 PM, Andrew Dunstan 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 against a vie
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 presumab
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 on
On Wed, Oct 17, 2012 at 7:25 PM, Tom Lane wrote:
> Josh Berkus 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
On Thu, Oct 18, 2012 at 6:46 AM, Andrew Dunstan 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 code, bu
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 p
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 spen
On Oct 17, 2012, at 4:45 PM, Daniel Farina wrote:
> On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus 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-spre
Josh Berkus 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 claim? The on
On Wed, Oct 17, 2012 at 3:24 PM, Josh Berkus 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 from what
On 17 October 2012 23:24, Josh Berkus 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 "well, they're no
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
On Wed, Oct 17, 2012 at 5:45 PM, Daniel Farina 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 Slony + Londist
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus 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 for. Tom al
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
> 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 peop
On Wed, Oct 17, 2012 at 12:43 PM, Andrew Dunstan wrote:
>
> On 10/17/2012 03:06 PM, Daniel Farina wrote:
>>
>> On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan
>> wrote:
>
> Triggers necessarily operate on a row-at-a-time basis. In theory,
> for at least some bulk operations, a rule
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan 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
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 exp
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan 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 the advan
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 17 October 2012 18:46, Greg Stark 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
> desired
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).
> 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 (pgsql-hack
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
Greg Stark 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.
Agreed. I t
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 whe
On 17 October 2012 18:46, Greg Stark 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
> desired r
On 17 October 2012 18:50, Andrew Dunstan 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 rule could
On 10/12/12, Josh Berkus 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 removed them.
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 t
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
Warning:
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
On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
Peter Geoghegan 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 upgrade STATEMENT trigg
On 17 October 2012 18:02, Joshua D. Drake wrote:
> Note: Do not use, use Triggers with Functions instead
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 your applications using
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 rule
On 12 October 2012 10:08, Daniel Farina wrote:
> On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs 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 fea
Peter Geoghegan 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 wasting their breath, be
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 o
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 02:14:34PM +0100, Peter Geoghegan wrote:
> On 15 October 2012 00:30, Greg Stark 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 b
On 15 October 2012 18:43, Josh Berkus 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 help!
>From me, t
On Mon, Oct 15, 2012 at 12:30:56AM +0100, Greg Stark wrote:
> On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs wrote:
> > On 12 October 2012 19:48, Greg Stark wrote:
> >> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
> >>> AFAICS all RULEs can be re-expressed as Triggers or Views.
> >>
> >> Th
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.
http:
On 10/15/2012 12:41 PM, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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
On 15 October 2012 14:43, Andrew Dunstan wrote:
>
> On 10/15/2012 09:07 AM, Simon Riggs wrote:
>>
>> On 15 October 2012 11:41, Greg Stark wrote:
>>>
>>> On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs
>>> wrote:
Please can anyone show me the SQL for a rule that cannot be written as
a
On 10/15/2012 09:07 AM, Simon Riggs wrote:
On 15 October 2012 11:41, Greg Stark wrote:
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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
On 15 October 2012 00:30, Greg Stark 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 happen afte
On Monday, October 15, 2012 03:07:21 PM Simon Riggs wrote:
> On 15 October 2012 11:41, Greg Stark wrote:
> > On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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 exis
On 15 October 2012 11:41, Greg Stark wrote:
> On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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 pro
On 15 October 2012 11:41, Greg Stark wrote:
> On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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 pro
On Mon, Oct 15, 2012 at 8:00 AM, Simon Riggs 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 a view doesn't help
On 15 October 2012 00:30, Greg Stark wrote:
> On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs wrote:
>> On 12 October 2012 19:48, Greg Stark wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
>>>
>>> This is a bizarre disc
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
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Simon Riggs
> Sent: Sunday, October 14, 2012 5:30 PM
> To: Tom Lane
> Cc: Greg Stark; Peter Geoghegan; PostgreSQL-development
> Subject: Re:
On Sun, Oct 14, 2012 at 9:30 AM, Simon Riggs wrote:
> On 12 October 2012 19:48, Greg Stark wrote:
>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs 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.
>> Th
On 14 October 2012 17:35, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 October 2012 19:48, Greg Stark wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
>
>>> This is a bizarre discussion. Firstly this isn't even clos
On Oct 14, 2012, at 12:35 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 October 2012 19:48, Greg Stark wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs wrote:
AFAICS all RULEs can be re-expressed as Triggers or Views.
>
>>> This is a bizarre discussion. Firstly this isn't eve
Simon Riggs writes:
> On 12 October 2012 19:48, Greg Stark wrote:
>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs 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 discont
On 13 October 2012 21:15, Joshua Berkus 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 if you
On 12 October 2012 19:48, Greg Stark wrote:
> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs 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 a
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
f
On 12 October 2012 17:59, 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 v
On 10/12/2012 08:48 PM, Greg Stark wrote:
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs 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*
e
On Fri, Oct 12, 2012 at 3:10 PM, Peter Geoghegan wrote:
> On 12 October 2012 20:01, Robert Haas wrote:
>> We know that rules are a bad fit for
>> almost everything, *but we can't assume that our users all know that
>> when it isn't even documented*.
>
> I agree that we should document that rules
On Thu, Oct 11, 2012 at 8:52 PM, Andrew Dunstan 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 partitioning
> either. Pers
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 s
On 12 October 2012 20:01, Robert Haas wrote:
> We know that rules are a bad fit for
> almost everything, *but we can't assume that our users all know that
> when it isn't even documented*.
I agree that we should document that rules are something that should
almost certainly be avoided. Up until r
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.
Lemm
On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs 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 they were then they
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 understandin
> 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 Thu, Oct 11, 2012 at 05:20:14PM -0700, Daniel Farina wrote:
> On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake
> 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 into 9.3 b
On Friday, October 12, 2012 01:45:56 AM Peter Geoghegan wrote:
> On 11 October 2012 20:28, Simon Riggs 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 do they ma
On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs 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 narrowly used than
ru
On 10/12/2012 08:47 AM, Simon Riggs wrote:
On 12 October 2012 01:52, Andrew Dunstan 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 chan
;
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
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
databas
On 12 October 2012 00:45, Peter Geoghegan wrote:
> On 11 October 2012 20:28, Simon Riggs 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 do they make more difficult?
On 12 October 2012 01:52, Andrew Dunstan 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.
This would be a doc
On 11 October 2012 23:59, Josh Berkus 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 things as bugs
Josh Berkus 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 RULES will be going away RSN.
2. In 9.4, send
esql.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
> wrote:
> >> On 10/11/2012 03:59 PM, Josh Berkus wrote:
> >>
> >>> I'm also not
FWIW I thought the stuff in commit 092d7ded2 might be pretty useful
generally.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom and Simon wrote:
>> If you want to get rid of rules, build the
>> replacement; don't just try to be a pain in the ass to users.
> Supporting broken and non-standard features *is* a pain in the ass to
> users, since they are sometimes persua
1 - 100 of 113 matches
Mail list logo
