Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oT33d-0001yl-FN for pgsql-admin@arkaria.postgresql.org; Tue, 30 Aug 2022 15:21:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oT33b-0007nl-Gc for pgsql-admin@arkaria.postgresql.org; Tue, 30 Aug 2022 15:21:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oT33b-0007nc-4i for pgsql-admin@lists.postgresql.org; Tue, 30 Aug 2022 15:21:39 +0000 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oT33Y-0000n9-OV for pgsql-admin@lists.postgresql.org; Tue, 30 Aug 2022 15:21:38 +0000 Received: by mail-qv1-xf34.google.com with SMTP id w4so8699580qvs.4 for ; Tue, 30 Aug 2022 08:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:message-id:subject:date:mime-version:from :content-transfer-encoding:from:to:cc; bh=wAvtDXVrpwxPrRrRrzFNyAcjKU8SeQzsCDrqOyHQ/vc=; b=a4sJe5FTvPX5YEmPh/55aosihY+Q9yDHXobYXcINwFZxnIuYxw/dxfKRv9EkvOp2et eJL/HW7U7X1ATH4G0Ac4+F+uDUVWT6lDgAWyGTj0CEPhItiTTx+7ynm3KlBdGQVkvlIo oslKYjzP2Tu4viLXVKo7GKwYrT+7r2sctpL3IZIUePhH5lYRIaKwB4YGexBgY/uDq3rc zVU8oFUPIcyJlskcNFReW/SYbAuYC/orjStA2gh6yjerD5bdAGeR/uxveG0a70bs9c3l 5yXDjlprx9h5Dv/Z41M1yoeiqNO+sSqWLQsUp1xzvdD0TDmbJyvxP7eUQVZl7VdOI9eA 8mwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:message-id:subject:date:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc; bh=wAvtDXVrpwxPrRrRrzFNyAcjKU8SeQzsCDrqOyHQ/vc=; b=790DstBBWDrM6x2RymlNAbIwSS+zKQr3lMkDeDX72cb/7giFa01RtlqvfCEX8zyfBv YrmLjQ4xRCxeOJDpBTtq5XOaAObrXoJU18+tIrjZs3avkf038wJJ7hqIdT50HSRvT/xq EUAFTbqjSkb053dMrkHWe9nM8M1c0mF0TgBfYG5lyu5GWHGm2kWZ2DiVBcV6RSVhUbwf YKbdkHtWBNJPu2E3Uk/J3fJbLeNhOvWluVNcsq2sKPkJ/CQDmw/+D5kCtrP9b37n7eWU Wag+P5TKluzIIsc6LW7CEjYzoNwrLPeAHoNCqa2sJj42rdvD7ohZgevmmMr8TRT7A58L BrHA== X-Gm-Message-State: ACgBeo3+ogfcJ1KUG5qi04Nkdf7kowx7u5+aQAHQZugA2aN6qrPPgpeo zrbQrDbcrqwd6LY/b7Am0xdHx5dQ2ZQ= X-Google-Smtp-Source: AA6agR4AeRqGDiMlojLGPFoZwvBl6d/zGAumRaGrFyUykcdFJ9YDfqr1+iPbgQmP8hf6NwtwoiyLjw== X-Received: by 2002:ad4:5e89:0:b0:498:fdc3:9450 with SMTP id jl9-20020ad45e89000000b00498fdc39450mr10277458qvb.77.1661872894481; Tue, 30 Aug 2022 08:21:34 -0700 (PDT) Received: from smtpclient.apple (h249.176.133.40.dynamic.ip.windstream.net. [40.133.176.249]) by smtp.gmail.com with ESMTPSA id n19-20020ac85b53000000b003447c4f5aa5sm7387554qtw.24.2022.08.30.08.21.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Aug 2022 08:21:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: John Scalia Mime-Version: 1.0 (1.0) Date: Tue, 30 Aug 2022 11:21:26 -0400 Subject: Two PostgreSQL instances returning different output for same query Message-Id: To: Pgsql-admin X-Mailer: iPad Mail (19G82) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I=E2=80=99m a bit stumped on this one. For one of my application teams both t= heir DEV instance and UAT instance are running pg version 12.3 in AWS RDS, a= nd I=E2=80=99ve used the same psql version 13.4. The query is a simple: SELECT to_jsonb(geom) FROM addresses LIMIT 1; On both databases the geom field is of data type geometry from postgis, but t= he two dbs are running different versions of Postgis. DEV is 3.0.2 while UAT= is 2.5.2, but I don=E2=80=99t think this is causing the issue. Running the query on the DEV instance produces=20 to_jsonb =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94- {=E2=80=9Ctype=E2=80=9D: =E2=80=9CPoint=E2=80=9D, =E2=80=9Ccoordinates=E2=80= =9D: [-106.54569, 31.82908]} While running it on the UAT instance produces to_jsonb =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=9C0101000020E610009000000000000000=E2=80=9C If I remove the to_jsonb() so the query becomes SELECT geom FROM addresses; = both output the same very long string that the UAT instance produces for th= e to_jsonb() output. So UAT does not seem to be processing the to_jsonb. I=E2=80=99m thinking that there might be a GUC controlling the output format= , but I can=E2=80=99t seem to find any references for one. Any ideas? Jay Sent from my iPad=