Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e30SR-0000CE-3E for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Oct 2017 13:56:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e30SQ-0003Oz-Fg for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Oct 2017 13:56:58 +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 1e30Qq-0000da-W5 for pgsql-hackers@postgresql.org; Fri, 13 Oct 2017 13:55:21 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e30Qj-0005V6-4d for pgsql-hackers@postgresql.org; Fri, 13 Oct 2017 13:55:19 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 451D721C1E45; Fri, 13 Oct 2017 16:55:12 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Received: from mail.postgrespro.ru (unknown [192.168.27.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 10CBD21C1E29; Fri, 13 Oct 2017 16:55:12 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1507902912; bh=IggvwBdf/JYWl+jHTSTjxY54dF4Gjs0SBk6XjF9u1d0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KgvTQr7nUeJmo48FdhrOWCTFlAGxnwz+VLFu6XhuNbq2qfsq6x8hRhyVRyv/rI4iu ZhabdysWPH9sqJBKUoksbmcSYPD045if6MEcQcDEwnt2ypGU2m3V1bEVC/EULPvPOs 6KZcWnyciJ6TwxAOz/r8P3mMKAxvB+JxvCeKVxns= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 13 Oct 2017 16:55:12 +0300 From: Victor Drobny To: Alexey Chernyshov Cc: Thomas Munro , Robert Haas , pgsql-hackers@postgresql.org Subject: Re: new function for tsquery creartion Organization: Postgres Professional In-Reply-To: <20171013163732.1bb85695@PostgresPro-A-Chernyshov> References: <69234700d26674fc7c171e48b850824c@postgrespro.ru> <20171013163732.1bb85695@PostgresPro-A-Chernyshov> Message-ID: <3e1b0851d3a6a2da42f78d31cc241d0b@postgrespro.ru> X-Sender: v.drobny@postgrespro.ru User-Agent: Roundcube Webmail/1.2.4 List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2017-10-13 16:37, Alexey Chernyshov wrote: > Hi all, > I am extending phrase operator is such way that it will have > syntax that means from n to m words, so I will use such syntax () > further. I found that a AROUND(N) b is exactly the same as a <-N,N> b > and it can be replaced while parsing. So, what do you think of such > idea? In this patch I have noticed some unobvious behavior. Thank you for the interest and review! > # select to_tsvector('Hello, cat world!') @@ queryto_tsquery('cat > AROUND(1) cat') as match; > match > ------- > t > > cat AROUND(1) cat is the same is "cat <1> cat || cat <0> cat" and: > > # select to_tsvector('Hello, cat world!') @@ to_tsquery('cat <0> cat'); > ?column? > ------- > t > > It seems to be a proper logic behavior but it is a possible pitfall, > maybe it should be documented? It is a tricky question. I think that this interpretation is confusing, so better to make it as <-N, -1> and <1, N>. > But more important question is how AROUND() operator should handle stop > words? Now it works as: > > # select queryto_tsquery('cat <2> (a AROUND(10) rat)'); > queryto_tsquery > ------------------ > 'cat' <12> 'rat' > (1 row) > > # select queryto_tsquery('cat <2> a AROUND(10) rat'); > queryto_tsquery > ------------------------ > 'cat' AROUND(12) 'rat' > (1 row) > > In my opinion it should be like: > cat <2> (a AROUND(10) rat) == cat <2,2> (a <-10,10> rat) == cat <-8,12> > rat I think that correct version is: cat <2> (a AROUND(10) rat) == cat <2,2> (a <-10,10> rat) == cat <-2,12> rat. > cat <2> a AROUND(10) rat == cat <2,2> a <-10,10> rat = cat <-8, 12> > rat It is a problem indeed. I did not catch it during implementation. Thank you for pointing it out. > Now operator can be replaced with combination of phrase > operator , AROUND(), and logical operators, but with operator > it will be much painless. Correct me, please, if I am wrong. I think that operator is more general than around(n) so the last one should be based on yours. However, i think, that taking negative parameters is not the best idea because it is confusing. On top of that it is not so necessary and i think it won`t be popular among users. It seems to me that AROUND operator can be easily implemented with , also, it helps to avoid problems, that you showed above. -- Victor Drobny Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers