Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOd6x-000KJ4-6X for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 12:59:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sOd6u-001pRn-QH for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 12:59:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOd6u-001pRe-DZ for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2024 12:59:53 +0000 Received: from meesny.iki.fi ([195.140.195.201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOd6r-0002OL-Pz for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2024 12:59:51 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4WD30K5KKBzyRc; Tue, 2 Jul 2024 15:59:45 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1719925186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i+MxgF9UC3V3ISgJnfUSTKtm3eaCMPdzWbpDlbVJaOc=; b=W2dGSblaoBd5iq5VEA/M65JJnWTbqUb82AJ9EXL1EwFeo3/0rs3EvKqDumJnPvxW0yVBUW TulVm0QukjWj4xs0wVjjD+gVVVxyVhNnjkRCbYn7hxVUyLwkLXB6n2sviyxDVxE5TzMqlV 59LUxpymBECIBLc9q5ftK4sBBbbfrhs= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1719925186; a=rsa-sha256; cv=none; b=X2f9GZwykp0ci2akLGSZ1eXWkXZAPVe5U+wVRZtJ2QPBLWtnBrVGMJJN2hKofedG1A8fhS MJo0TQe2797h42eXOqVdyBUiiJa+W+58izCSZXgorzVDTmCOyECicGZMPiEif7xg7PdaED quIILNFG1Lmi2FtU7sLWNgwk6kECiJQ= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1719925186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i+MxgF9UC3V3ISgJnfUSTKtm3eaCMPdzWbpDlbVJaOc=; b=RxLBxju0PBJYaDEW5Lx5uutZsloOxpvFz6NUBZmGb57Sza+xGbJZ76SrsSkDhzp9BRVbbR GBaC3obrFAqHNTq/4rI+Evv4/3iAeOdpEsnrckEGP9+evHbdVsaXmqZriDMk/RqhHwScex JBW2En5YvgVCHzNGXkoge3mBUjdqYZo= Message-ID: Date: Tue, 2 Jul 2024 15:59:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Inline non-SQL SRFs using SupportRequestSimplify To: Paul Jungwirth , PostgreSQL Hackers References: <09de6afa-c33d-4d94-a5cb-afc6cea0d2bb@illuminatedcomputing.com> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: <09de6afa-c33d-4d94-a5cb-afc6cea0d2bb@illuminatedcomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 28/06/2024 01:01, Paul Jungwirth wrote: > If it seems good to let people use SupportRequestSimplify to make their SRFs be inlineable, I'm > happy to add tests and docs. We should really document the idea of inlined functions in general, so > I'll do that too. > > Another approach I considered is using a separate support request, e.g. SupportRequestInlineSRF, and > just calling it from inline_set_returning_function. I didn't like having two support requests that > did almost exactly the same thing. OTOH my current approach means you'll get an error if you do this: > > ``` > postgres=# select temporal_semijoin('employees', 'id', 'valid_at', 'positions', 'employee_id', > 'valid_at'); > ERROR: unrecognized node type: 66 > ``` > > I'll look into ways to fix that. If the support function returns a Query, we end up having a FuncExpr with a Query in the tree. A Query isnt an Expr, which is why you get that error, and it seems like a recipe for confusion in general. Perhaps returning a SubLink would be better. I think we should actually add an assertion after the call to the SupportRequestSimplify support function, to check that it returned an Expr node. +1 to the general feature of letting SRFs be simplified by the support function. > I think SupportRequestSimplify is a really cool feature. It is nearly like having macros. > I'm dreaming about other ways I can (ab)use it. :-D -- Heikki Linnakangas Neon (https://neon.tech)