Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edh2C-0006Ex-QL for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jan 2018 18:41:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edh2C-0007gn-Dt for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jan 2018 18:41:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1edh2C-0007gc-7J for pgsql-hackers@lists.postgresql.org; Mon, 22 Jan 2018 18:41:32 +0000 Received: from mail-wr0-x236.google.com ([2a00:1450:400c:c0c::236]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1edh27-0001Tv-Tz for pgsql-hackers@postgresql.org; Mon, 22 Jan 2018 18:41:31 +0000 Received: by mail-wr0-x236.google.com with SMTP id t16so9776810wrc.10 for ; Mon, 22 Jan 2018 10:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yCnU10JJ9rdhBGReQuuIHacanXUVNA0jpunIcEFsCQw=; b=AKqsrlup5B0R7YCdm/qL+WoChkf0Wk5TrFcnzQuKbOUS4rWwsezpkX9bpWlgwrrYIl CTGiKKbF/JSDCHe2sr84se7LIrXQWnJA3zdFFZTSO+Vm/xxe33a+Ja5L6nz86wgcIOIB A88yf82iA+THxgdiE0B2GOBfS5g8PZJiox9ZDrU37+k7y2lS9OBxHzYiWK4W2higW97h T28B3U4b6PKYGQRTrWpE1k/9SCR67POvOoIwz8Fb63J1aMiAkCLveEmVS5Ka9ga3wB1m gKWkHIzvfgdce7CFv0IlC83+yDBCZyGn2upnQvSlcDZ/zhsNpUhjwb/GB2jX2yWmb+kp Derg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yCnU10JJ9rdhBGReQuuIHacanXUVNA0jpunIcEFsCQw=; b=Vv+tFfHlkkdAAQDduBwVq7ml7ewur05suxDpJhO7gIwMkc65LefITguIMZ7t/CtKeR pC5JDvRkKjUDyM3lctlW0PazJaYxVenf8tb0hbOwjfGLje3wbn4kdhJMjbtyi9n9fFVo 2ysc9VeFjK3Y5c8n91L2GAbDwcjV6h76MLXIjguVgaprU/gzfxE6erAikjkVmTNsQyue /pot8Q40UaguONG3EjqwEhvp4p3KizCHwdsJIUEiqBq6fZzEwqNt/I7nsM2J4aY6BbVB hR8tfbeHaxKoM6IntRHbeH1wrw+tHeEcAHP1+F8dShL9F6lg30QiDVCzx5+7Mire0OVz latA== X-Gm-Message-State: AKwxytc0EfNNvgQWpM2Qy7O0X9iXJVqKXoSleojwf1zeqXJ5yjvxexbF IGKF8cAVweHrnYq+4pIPGj3BOqJ3jQ1tt2BfAP09lUMDVSrCUglRMTdjnZbJg2Fdd2BZyLvWbWz Umyq1wjsoL+N7mSohw/CfGXr/P0HCatbp2WtVswmnnWhXyeMhzVyOdudXqfKPh+N7etjdTvp++H xZcfJk3+zTkg== X-Google-Smtp-Source: AH8x224eF98roma+7h8vVz4dNVsyszZXNxbVuBzdFraDQxzR4OkHyptOL8hBQ27riu3RErjcG7rlww== X-Received: by 10.223.199.15 with SMTP id k15mr7348133wrg.279.1516646486468; Mon, 22 Jan 2018 10:41:26 -0800 (PST) Received: from [192.168.0.3] (ath91-3-88-167-161-184.fbx.proxad.net. [88.167.161.184]) by smtp.gmail.com with ESMTPSA id m6sm1683934wmb.6.2018.01.22.10.41.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 10:41:25 -0800 (PST) Subject: Re: PATCH: psql tab completion for SELECT To: Edmund Horner , PostgreSQL-development References: From: Vik Fearing Organization: 2ndQuadrant France Message-ID: <326b26f4-e1d4-c2f1-9110-aae396193f15@2ndquadrant.com> Date: Mon, 22 Jan 2018 19:41:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 01/12/2018 06:59 AM, Edmund Horner wrote: > Hi, here's a new patch. > > This one makes some changes to the criteria for which functions to > include; namely filtering out trigger functions and those that take or > return values of type "internal"; and including aggregate and window > functions. Some of the other checks could be removed as they were > covered by the "internal" check. This looks better. One minor quibble I have is your use of != (which PostgreSQL accepts) instead of <> (the SQL standard). I'll let the committer worry about that. > It also uses the server version to determine which query to run. I > have not written a custom query for every version from 7.1! I've > split up the server history into: > > pre-7.3 - does not even have pg_function_is_visible. Not supported. > pre-9.0 - does not have several support functions in types, languages, > etc. We don't bother filtering using columns in other tables. > pre-9.6 - does not have various aggregate support functions. > 9.6 or later - the full query I'm not sure how overboard we need to go with this going backwards so what you did is probably fine. > I was able to test against 9.2, 9.6, and 10 servers, but compiling and > testing the older releases was a bit much for a Friday evening. I'm > not sure there's much value in support for old servers, as long as we > can make completion queries fail a bit more gracefully. pg_dump stops at 8.0, we can surely do the same. Now for some other points: Your use of Matches1 is wrong, you should use TailMatches1 instead. SELECT is a fully reserved keyword, so just checking if it's the previous token is sufficient. By using Matches1, you miss cases like this: SELECT (SELECT It also occurred to me that SELECT isn't actually a complete command (or whatever you want to call it), it's an abbreviation for SELECT ALL. So you should check for SELECT, SELECT ALL, and SELECT DISTINCT. (The FROM tab completion is missing this trick but that's a different patch) -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support