Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMgcv-00051q-Uq for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Apr 2020 23:30:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jMgcu-0004Mf-Jn for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Apr 2020 23:30:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMgcu-0004MY-8h for pgsql-hackers@lists.postgresql.org; Thu, 09 Apr 2020 23:30:28 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jMgcr-0001Pr-7J for pgsql-hackers@lists.postgresql.org; Thu, 09 Apr 2020 23:30:27 +0000 Received: by mail-qt1-x843.google.com with SMTP id z90so265168qtd.10 for ; Thu, 09 Apr 2020 16:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=W05/ys4/0nYT8LNICZUe5MojQ1TJRhKsDWBLI3C+/lY=; b=BTyZsOJAUs4MpeDGjDhmy84bl3HrO4mZsi9LwLzE2gYEh/H876UDiEp59ybj8rgBdm 31LLZ3witTuCCGNYPa38Vo4963fm3cxIJPb2zUK/y74blus7VybturE4dyUl7bHsBoMK PHV9lBQ8Qb1zJxDUSi5xjGT4bsaWhmNAIKy29JGOb3SzuJa4uvbADOnP+580nFB0IvVY aHCGwgAPdzxgOoeS/K/sZRdwPVCvO/lhyVRq8g6WmA9lFbUSCSbgrLPNVftAoG1dm0HB WhIAJhrAH4WE0BnJMVB+OPxjaQyas7D2BRQNfP4aBScZMldFrOpSbF+kL8CV56u/5f0D Wrfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=W05/ys4/0nYT8LNICZUe5MojQ1TJRhKsDWBLI3C+/lY=; b=WUnA6vJhdVwXUQQNKGRqNz3arG3wQ0wo0N4earvWoIr+8dTEunfLgkTqPzYvboxIzA mD6fLixTMo/XUDb9lwhFdFp+UDBS2+ncMA2sffGU/K8GGB7HuKmqE23lEdlZbyqqWyUc 8UtBoec7AltN2VU8suNivb2rHcQhnFgxPArVIHbi7s6lEzdh/gFCkcMHGk7pco+EBZAz FDBIwJLur9fmALHfoG9BoSkg2tj3lxXBBcCxwMNCn3m6aFOUJ8Ar+1IPriNs5/8C0dLk 0eDYB58qlAvxlF27XSd74qT1+nnELBcc1GcCeYTW8MOvAIyUfSDJFVJa1FWv9Bj2Za6E OGjw== X-Gm-Message-State: AGi0PuaORX/WjIkxlijyhM0UMgwvB4XqkMTF4Y9nWBA76JsahQrfoLS/ iDldqF69DBpIdfQQIeRpE+RFhw== X-Google-Smtp-Source: APiQypKIZy1aYIAtSahS5RhVCYBNIHUIg2y9VTXU6hdZlEn1VAbMjkhbdxvebgH+hGDd0Oh2YBQcIg== X-Received: by 2002:ac8:46d0:: with SMTP id h16mr2003185qto.242.1586475023485; Thu, 09 Apr 2020 16:30:23 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id i18sm288580qtp.8.2020.04.09.16.30.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2020 16:30:22 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 70F41300B23; Thu, 9 Apr 2020 19:30:19 -0400 (-04) Date: Thu, 9 Apr 2020 19:30:19 -0400 From: Alvaro Herrera To: Tom Lane Cc: Ibrar Ahmed , Ahsan Hadi , PostgreSQL Hackers Subject: Re: more ALTER .. DEPENDS ON EXTENSION fixes Message-ID: <20200409233019.GA26510@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3926.1583937053@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Mar-11, Tom Lane wrote: > BTW, I did not like the syntax too much. "NO DEPENDS ON EXTENSION" > doesn't seem like good English. "NOT DEPENDS ON EXTENSION" is hardly > any better. The real problem with both is that an ALTER action should > be, well, an action. A grammar stickler would say that it should be > "ALTER thing DROP DEPENDENCY ON EXTENSION ext", but perhaps we could > get away with "ALTER thing DROP DEPENDS ON EXTENSION ext" to avoid > adding a new keyword. By that logic the original command should have > been "ALTER thing ADD DEPENDS ON EXTENSION ext", but I suppose it's > too late for that. The problem with DROP DEPENDS is alter_table_cmd, which already defines "DROP opt_column ColId", so there's a reduce/reduce conflict for the ALTER INDEX and ALTER MATERIALIZED VIEW forms because "depends" could be a column name. (It works fine for ALTER FUNCTION/ROUTINE/PROCEDURE/TRIGGER because there's no command that tries to define a conflicting DROP form for these.) It works if I change DEPENDS to be type_func_name_keyword (currently unreserved_keyword), but I bet we won't like that. (DEPENDENCY is not a keyword of any kind, so DROP DEPENDENCY require us making it one of high reservedness, which I suspect we don't like either). It would also work to use a different keyword in the DROP position; maybe REMOVE. But that's not a keyword currently. How about ALTER .. REVOKE DEPENDS or DELETE DEPENDS? Bison is okay with either of those forms. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services