Re: [HACKERS] Deprecating RULES

[Stirling Newberry]

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 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 object 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 alvhe...@2ndquadrant.com
 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 alvhe...@2ndquadrant.com 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