Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGES2-0005JU-CV for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Nov 2017 01:31:14 +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 1eGES0-0007Y2-GU for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Nov 2017 01:31:12 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eGERz-0007Xs-Pk for pgsql-hackers@lists.postgresql.org; Sun, 19 Nov 2017 01:31:12 +0000 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eGERs-0007e2-2P for pgsql-hackers@postgresql.org; Sun, 19 Nov 2017 01:31:10 +0000 Received: by mail-wm0-x22b.google.com with SMTP id y80so12611402wmd.0 for ; Sat, 18 Nov 2017 17:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Z89vBB5nBTzSyIxzaXAY3fR3WG66Lpe6h2FM7vxlvUI=; b=YpuI9HqppRnLiUMbg/iXpX2geUQHf73a6zSVLB/mmHnXRzgPCZgOL3m+v38t8GmjXv B0g9sdgUeGtp/+WNJr4EXeS2ID8TDgeTmYue6maNBh60MxBBWw2iLRA2MYIpB+nLAF8T nb0ZIFG7fetOAmL/lGha+ErP4IldPflC+5zTgrB3LbZrkyDvVq6PVWayXgfj983M/W5x 1Psaw6NG7RQxBnNlzvuoprBd/CO00rNBK8u/Fgy+uvoRQf4mVtHJelgxVEPxhjq8hlR5 uNGkI+N7vJflqqCONLfj0Vkw/tRrrFx9ctuIg05Syw3ri2Dwr5VonPpLJij/nGbATlS4 TwIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Z89vBB5nBTzSyIxzaXAY3fR3WG66Lpe6h2FM7vxlvUI=; b=S1e11GcDfMKsMrhuIUSi7XrhSpYlmvIk6MEqa723s9n8u/7Jgy/xcRSY5oEuzfS0qN T9cUhLFFNY0HqWO14CfCOE1OJW90pKttwZNGsvxRa+P8N6EaE6rP7qIMwg1HHZIyM/Od 7xKn75VZBDUF1KBn8Ra5zPWxrk5h/aH1Ss5qbLwk8zXrOYuBuSSzfvYYJmA8v1WOJeQY VjIgpoTrbgAFY6bvubjyVKe1KRKkrCMyAr4RJjITv/GxgK7kr8qDJ1cxnPLU5SEdJa6j h7ab+z2mE78cGpprb4NTy7FFmuk6s/gs7jA/kp1zQ0nVOSmqjVysQR4NfpHtOd2/0Xry hotw== X-Gm-Message-State: AJaThX7q7kJuls85jijHW9VsJ/vlJAs1zAMmwRY/ms+sKxrHCjD6/5RE nSpndc5e0LeRpijNqo910Uxx9J3iQFU0VZXb7NMMcRsw+NcdPX4vICQpizqkgdyEkhp8U6n57+I 6igyqimErBPJgUqSSlQiknVBC2dYBYdE7N8LZPgewxcGbeu7JozVsP6hRPtLeX9bNUDXqP1uGDL edyEUwkGCt X-Google-Smtp-Source: AGs4zMY+vP39fVFl2a4wikenjQtNsRDJaTGqii0YljZb7nx81d7b2z1T3EZDg3fa8V1f4PjJkmSbrQ== X-Received: by 10.28.102.6 with SMTP id a6mr7024847wmc.63.1511055061717; Sat, 18 Nov 2017 17:31:01 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id p200sm6278283wmd.9.2017.11.18.17.30.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 17:31:00 -0800 (PST) Subject: Re: [HACKERS] new function for tsquery creartion To: Victor Drobny , Thomas Munro Cc: Robert Haas , pgsql-hackers@postgresql.org References: <69234700d26674fc7c171e48b850824c@postgrespro.ru> From: Tomas Vondra Message-ID: Date: Sun, 19 Nov 2017 02:30:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <69234700d26674fc7c171e48b850824c@postgrespro.ru> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 09/13/2017 10:57 AM, Victor Drobny wrote: > On 2017-09-09 06:03, Thomas Munro wrote: >> Please send a rebased version of the patch for people to review and >> test as that one has bit-rotted. > Hello, > Thank you for interest. In the attachment you can find rebased > version(based on 69835bc8988812c960f4ed5aeee86b62ac73602a commit) > I did a quick review of the patch today. The patch unfortunately no longer applies, so I had to use an older commit from September. Please rebase to current master. I've only looked on the diff at this point, will do more testing once the rebase happens. Some comments: 1) This seems to mix multiple improvements into one patch. There's the support for alternative query syntax, and then there are the new operators (AROUND and ). I propose to split the patch into two or more parts, each addressing one of those bits. I guess there will be two or three parts - first adding the syntax, second adding and third adding the AROUND(n). Seems reasonable? 2) I don't think we should mention Google in the docs explicitly. Not that I'm somehow anti-google, but this syntax was certainly not invented by Google - I vividly remember using something like that on Altavista (yeah, I'm old). And it's used by pretty much every other web search engine out there ... 3) In the SGML docs, please use instead of just quoting the values. So it should be | instead of '|' etc. Just like in the parts describing plainto_tsquery, for example. 4) Also, I recommend adding a brief explanation what the examples do. Right now there's just a bunch of queryto_tsquery, and the reader is expected to understand the output. I suggest adding a sentence or two, explaining what's happening (just like for plainto_tsquery examples). 5) I'm not sure about negative values in the operator. I don't find it particularly confusing - once you understand that (a b) means "there are 'k' words between 'a' and 'b' (n <= k <= m)", then negative values seem like a fairly straightforward extension. But I guess the main question is "Is there really a demand for the new operator, or have we just invented if because we can?" 6) There seem to be some new constants defined, with names not following the naming convention. I mean this #define WAITOPERAND 1 #define WAITOPERATOR 2 #define WAITFIRSTOPERAND 3 #define WAITSINGLEOPERAND 4 #define INSIDEQUOTES 5 <-- the new one and #define TSPO_L_ONLY 0x01 #define TSPO_R_ONLY 0x02 #define TSPO_BOTH 0x04 #define TS_NOT_EXAC 0x08 <-- the new one Perhaps that's OK, but it seems a bit inconsistent. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services