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 1s44E4-000N14-DF for pgsql-admin@arkaria.postgresql.org; Mon, 06 May 2024 19:42:16 +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 1s44E0-00FWtT-P8 for pgsql-admin@arkaria.postgresql.org; Mon, 06 May 2024 19:42:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s44E0-00FWtL-AM for pgsql-admin@lists.postgresql.org; Mon, 06 May 2024 19:42:13 +0000 Received: from mout-u-107.mailbox.org ([2001:67c:2050:101:465::107]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s44Dy-001tIC-6R for pgsql-admin@lists.postgresql.org; Mon, 06 May 2024 19:42:12 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4VYBcr5k15z9syD; Mon, 6 May 2024 21:42:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1715024524; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b44+WKUINrQnTtVxC66k5JO0aM+4oLyzQ5oOnDgwSfE=; b=eQqUJdFBkFThalbFj/KBSfP8nFUtPphMxJ0OEqqDHi7iqyr3nOz7rINCoU1XodhJXuWh6H yHiMmT6qy12pnVwhMzf/8dYdeSOl0WuBRDGdORsHlJAEv5P1FlCxbRKBCYyhv7o5PVOOtL qy6g1WBCd/HQRFlafGwWi8EFFkSGf+ypFRrTZq2GDhDgK+2lADG/fHDaF6UoWjzWn88xUo Tt1IT0AOMXcKSa40uKy4o7K1fEH74g+uMJ1HIt/DJuTun8cG8L+ivrAzC3gFOvm89lWroH n8H3YJt+uXipKu4u2Y5LWJD6FSxiYXhVJwjpkU4+odivB2Cv4LD+58trz7M15g== Date: Mon, 6 May 2024 21:42:02 +0200 From: Erik Wienhold To: M Sarwar Cc: "pgsql-admin@lists.postgresql.org" Subject: Re: ERROR: return and sql tuple descriptions are incompatible Message-ID: <3e96cfd1-e6fb-4a25-97c1-bd2c74284f78@ewie.name> References: <7kadkskdcixknub2dvc4ovm24q5thdptxj2opu42pninbadonm@h5opztcvzcrh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4VYBcr5k15z9syD List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-05-06 17:04 +0200, M Sarwar wrote: > Now I have changed from ORDER BY 1,2 to ORDER BY 1. This works because your input query only returns one category. But then you don't need crosstab because you effectively only execute: SELECT * FROM crosstab($$ SELECT PART.SERIAL_NUMBER, TESTC.TEST_NUMBER, TRESULT.TEST_RESULT FROM ... WHERE TESTC.TEST_NUMBER = 'TEST1P1' ORDER BY 1 $$) AS ConcatenatedResults ( SERIALNUMBER varchar, TEST_RESULT numeric ) Which is the same as this plain query: SELECT PART.SERIAL_NUMBER AS SERIALNUMBER, TRESULT.TEST_RESULT FROM ... WHERE TESTC.TEST_NUMBER = 'TEST1P1' ORDER BY 1 Generally, you want something like ORDER BY 1,2 in the input query to control how crosstab assigns the up to N different categories to N value output columns *in a predictable manner*. With just ORDER BY 1 you rely on the unspecified order (at least when it comes to column 2) in which the query returns rows. > Sorting TEST_NUMBER is taken care while generating TEST_NUMBER columns data. Do you mean the order of inserts into test_test_details_all_mcm_init? You can't rely on that ordering in your queries unless you use ORDER BY. The unspecified ordering depends (among other things) on the tuple order on disk. Updating any of those rows affects that order because Postgres updates rows by writing new tuples. > Reference from the link. > > AS concatenated ( > SERIAL_NUMBER character varying(18), > TEST_RESULT_1 NUMERIC, > TEST_RESULT_2 NUMERIC > ) > > > Question on this: As per this, there is no need to define the column > TEST_NUMBER format. That means, database is identifying the category > column ( TEST_NUMBER ) on it's own. Am I right? With "TEST_NUMBER format" do you mean "output column"? If so, then yes, you don't specify an output column for that. Values in columns 1 and 3 are the only ones you see in the crosstab output. Column 2 (with the ORDER BY) only specifies whether test number 1 and 2 should be assigned to TEST_RESULT_1 and TEST_RESULT_2 or the other way round. This all is summarized in the docs[1]: "In practice the SQL query should always specify ORDER BY 1,2 to ensure that the input rows are properly ordered, that is, values with the same row_name are brought together and correctly ordered within the row. Notice that crosstab itself does not pay any attention to the second column of the query result; it's just there to be ordered by, to control the order in which the third-column values appear across the page." [1] https://www.postgresql.org/docs/current/tablefunc.html#TABLEFUNC-FUNCTIONS-CROSSTAB-TEXT -- Erik