Re: [HACKERS] Deprecating RULES

[Stirling Newberry]

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 even close to true.
>>> The whole source of people's discontentment is that triggers are *not*
>>> equivalent to rules. If they were then they wouldn't be so upset.
> 
>> I'm not aware of any rule that can't be rewritten as a trigger or a
>> view. Please can anyone show me some examples of those?
> 
> Sorry, you're thinking you can put the burden of proof on other people,
> but this doesn't work like that.  If you want to deprecate rules on the
> grounds that triggers are an adequate substitute, it's up to you to
> prove that claim, not for other people to disprove it.


It seems there are two somewhat separate issues for discussion, one is the 
question of what to do about rules, the second is deprecation policy in 
general. Having worked for major software vendors, this are is always a 
headache. Consider the Microsoft, one of the more powerful software vendors of 
the PC era, is still trying to get people to upgrade to IE6, but is facing the 
obstacle of businesses refraining because internally written applications. The 
discussions around rules and hash indexes going on concurrently on this list 
share features which would benefit from having a general policy discussion 
abstracted from the attachments or dislikes of particular features.  

I would suggest that a thread be spawned off to consider deprecation policy, 
including substantive reasons for deprecation, the burden of proof on those 
proposing deprecation, means of communicating to users. This will cause some 
thrash up front, but will go a long way to triaging deprecation discussions, 
and having a work flow in place for when such decisions are made.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CREATE SCHEMA IF NOT EXISTS

[Stirling Newberry]

This case points to a weakness in many programming languages, not having a 
clear ifof (if and only if) versus if construction. 

The sane use case for create schema foo if not exists  is for building 
a database dynamically, where several points may be the first to put a table in 
a schema, and schemas should not be created if there are no objects. The 
create/search/drop design pattern having its own problems.

Thus the construction should default to one behavior, and have an option for 
the second.

e.g.

create schema foo if not exists (will not be done if foo existed)
create schema foo if not exists FORCE (will be done even if foo existed)

This would even allow for mixed e.g. 

create schema foo if not exists (tables that should be created once and not 
again)
FORCE (objects routine will add if the schema does)




On Oct 2, 2012, at 6:33 PM, Fabrízio de Royes Mello wrote:

> 
> 2012/10/2 Alvaro Herrera 
> Excerpts from Andrew Dunstan's message of mar oct 02 17:24:38 -0300 2012:
> >
> > On 10/02/2012 03:48 PM, Tom Lane wrote:
> > > Alvaro Herrera  writes:
> 
> > >> Well, if that's the rationale then you end up with no schema foo at all
> > >> (i.e. both die), which seems even more surprising (though I admit it has
> > >> the advantage of being a simple rule to document.)
> > > I think we should just disallow putting any contained objects in the
> > > statement when IF NOT EXISTS is used.  It's simple to understand, simple
> > > to document and implement, and I think it covers all the sane use-cases
> > > anyway.
> >
> > I thought we'd already agreed on this.
> 
> Well, it's not what the latest proposed patch implements.
> 
> 
> You're right... the latest proposed patch don't implements it.
> 
> I'll change the patch and send soon...
> 
> Regards,
> 
> -- 
> Fabrízio de Royes Mello
> Consultoria/Coaching PostgreSQL
> >> Blog sobre TI: http://fabriziomello.blogspot.com
> >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
> >> Twitter: http://twitter.com/fabriziomello
>