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 1s9B0f-000Ius-4D for pgsql-novice@arkaria.postgresql.org; Mon, 20 May 2024 21:57:34 +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 1s9B0e-005fMK-WE for pgsql-novice@arkaria.postgresql.org; Mon, 20 May 2024 21:57:33 +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 1s9B0e-005fLQ-No for pgsql-novice@lists.postgresql.org; Mon, 20 May 2024 21:57:32 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9B0Y-001Bj1-QA for pgsql-novice@lists.postgresql.org; Mon, 20 May 2024 21:57:31 +0000 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a61b70394c0so151677866b.1 for ; Mon, 20 May 2024 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716242244; x=1716847044; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=VZnzf7kmZpUi41s05CO2upPcOUbnxZx2tqKkvkMDY1s=; b=GUOcLCFA34+yzK9p7fFHFKoi30sGxLXObtAjywxj0Q9usuhli9b4nGUajLdV4en61i OkjNXGOG+bpQDDkK221KXMbwsvJKB6fLixqk13BMe818n46NY8NBaJQFUmUUpb85vucy AZMMnNnbH7Ugf5FicNtUprFhYyG8UQsPofHQXS4d881dBwk/FYtoF+E39jGFThR5Ln0m xJMhw3c4gTh09wLYqxs2npS9ubJqgwfrYqMRRodX+dcYT1waaC1FEp2S2DlYlJFsLTin OVGOay+fMUKBqWeNFHgJBrO7ssoL5uQUE8HSSXH4uJYvwhqzcI+Q3IWynqWMaO0SizZo UHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716242244; x=1716847044; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VZnzf7kmZpUi41s05CO2upPcOUbnxZx2tqKkvkMDY1s=; b=JCAhm9XUURx7vN2MJCubx9508L6Y7ZEUESfT7kNTxXHuIYws4ZMHb8cH0dD9bBFg/t 6BHtx7h5TXRd2KkPqQXDqOwsIEELIiYL4BS39CEVlcUfx/tQwnkagks74CT/uQZzVkyl 0jHNkMm0AwzI328uveIBKm3XcxbVoVuvY010tb9nMAgAFBd/qB11sEhcBGeABmVYLwiP u8Kw/er7NELvGWDHeIj+vPO3sdZkD1MrpvC4uJat6lBgl4j43S3Ut2gLQfquuH47cO0r 0yyps8i7wBDnohwOezM48m3FT+Y3GHNwO75kSQ96zk2uJx1KqGPNMc+eqqrHNhcuBlUa MQ3w== X-Gm-Message-State: AOJu0YxNfsRdBfJ7dohfHZqbgqx9CeMu8jK8VoZXMaogj03BhW75tNru ZIYxLqkc3zqjMOWwHrUeEciwbi3zJRy++imwLjZJmiBHyO8rPUJeJiw7yQZJ1j1owg5Qp3lZq0Q ZGNaVFLGwmgkNyk9cEzC5/cvQwrE95dLY X-Google-Smtp-Source: AGHT+IEHToAn/RWsiGBgUINtkJM3FBMwTLdFtbv/v3EJBDjBUx65B7RdDnoDdWSdC6HDLFuxonrKaJEPDAYnDh/l7qk= X-Received: by 2002:a17:906:78b:b0:a59:ba2b:590e with SMTP id a640c23a62f3a-a5a2d65f27dmr1836384466b.48.1716242243807; Mon, 20 May 2024 14:57:23 -0700 (PDT) MIME-Version: 1.0 From: Matthew Mellon Date: Mon, 20 May 2024 17:56:47 -0400 Message-ID: Subject: INSERT ... SELECT nonpositional syntax To: pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000004a72120618e9c91f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004a72120618e9c91f Content-Type: text/plain; charset="UTF-8" I'm a PostgreSQL novice but a very, very experienced DBA from the SAP SQL Anywhere context (formerly Sybase / iAnywhere). Most of my code has been in the Watcom SQL dialect in the past. SAP's products have a nice feature not found in the ANSI standards for the INSERT ... SELECT syntax: WITH AUTO NAME. Assume you have a table that looks something like this: In PostgreSQL, you can: INSERT INTO TableX ( i, j, k ) SELECT a, b, c FROM TableY; -- or whatever SELECT expression you want returning possibly many rows This is nice, but it's so much nicer to have the destination columns adjacent to your source values: INSERT INTO TableX WITH AUTO NAME SELECT a i, b j, c k FROM TableY; I'm not complaining here, but just wondering if there is a way that the syntax can be extended at this level using an extension, or if there is a fighting chance of extending the syntax in the base product? Thanks, Matthew Mellon --0000000000004a72120618e9c91f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm a PostgreSQL novice but a very, very experienced D= BA from the SAP SQL Anywhere context (formerly Sybase / iAnywhere). Most of= my code has been in the Watcom SQL dialect in the past.

SAP's products have a nice feature not found in the ANSI standards for= the INSERT ... SELECT syntax: WITH AUTO NAME. Assume you have a table that= looks something like this:


In Post= greSQL, you can:

INSERT INTO TableX=C2=A0
(
=C2=A0 i,=C2=A0
=C2=A0 j,=C2=A0
=C2=A0 k<= /div>
)=C2=A0
SELECT a,=C2=A0
=C2=A0 b,=C2=A0
=
=C2=A0 c
FROM TableY; -- or whatever SELECT expression you w= ant returning possibly many rows

This is nice, but= it's so much nicer to have the destination columns adjacent to your so= urce values:

INSERT INTO TableX
WITH AUT= O NAME
SELECT a i,
=C2=A0 b j,
=C2=A0 c k
FROM TableY;

I'm not complaining here, = but just wondering if there is a way that the syntax can be extended at thi= s level using an extension, or if there is a fighting chance of extending t= he syntax in the base product?

Thanks,
<= br>
Matthew Mellon
--0000000000004a72120618e9c91f--