Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5Pya-0000Mf-U3 for pgsql-interfaces@arkaria.postgresql.org; Wed, 04 Sep 2019 07:45:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5PyZ-0004Kz-3E for pgsql-interfaces@arkaria.postgresql.org; Wed, 04 Sep 2019 07:45:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5PyY-0004Ks-PL for pgsql-interfaces@lists.postgresql.org; Wed, 04 Sep 2019 07:45:10 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5PyW-0001Rc-Iy for pgsql-interfaces@lists.postgresql.org; Wed, 04 Sep 2019 07:45:10 +0000 Received: by mail-lf1-x142.google.com with SMTP id w6so9685847lfl.2 for ; Wed, 04 Sep 2019 00:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=QE593mzuL7bSrnIrebejV1JmCvewh4DQ77sq/j4Q1JQ=; b=kf6DUEK0lJ3cgz/OUsogYw0nb4scGAy6U3rfbLaYDzONv/KobNMztrzj3z5igKJLpD CzSAjqPlhoJ/+WzN9xMHXeJtljSgeQM0r9XhFJgA2eChCUzEaN8B00Ox0ETZw5sAowwN fAXZ+tRMK/mHeUpXL2UpTOI59K4yFcHpi23VJUVaznDg5cuKtOB3qABbwQDYj/9xsDvV qrJ49sldu9gJIe0XDf1CGw9FHUTSwsJcr5YpjIODHsXmxsI/2Z8ANrnwpdnlc5Sknenp YXVD0yk7ryER5G1ErBNOAte1MvVDRfl2nVvSl65hzoI31sbKCuWI+13CiIPGKzgp5l7S k+Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=QE593mzuL7bSrnIrebejV1JmCvewh4DQ77sq/j4Q1JQ=; b=T9Ev+6M7MLA+hlTxJXD3qVYV/uOpEe6rPH2rq4pFpFe/cByc6jUjdCWLi4MTcAJCcC d9Wnj8+baaFKPNxiU9upn0nwRA102B5CJPS/1YpParQNRft3OC2Li+EqqzUoBpHOiGEB dNMCjVcRGwBWUS+vljsPZJjwb+XMw9WEZiTU8Xh+uY+YstoD4mDvJcsiu4T4CvVkm+NC iaxk+g1UjykSI2P1JsIsr+qtgAu4gOIsFLBVlNJGTfQ+/eZkAvIRuGnBBcSKkXzczjj8 wpyCVxFw6PKBKRydGdyjfLCdDhPDGXkFarM5NCkw98bIK3wOpBltdIOOLlsj0RNEZEUd AqUQ== X-Gm-Message-State: APjAAAXb1xze+YBy88a5E4qwqMe8xUU5JjNNjZRs24zvNKn/sf6Ib2DW Wtf+6kVLHm7xB4fpBQ+Y+QA= X-Google-Smtp-Source: APXvYqxz2vtIqBDIXFgDibJsZwDL4ANsc+BIzGaQLUDAx/FJFU/V+9wbpfu9n/nxgzEY81+WFxvbvg== X-Received: by 2002:a19:4b0d:: with SMTP id y13mr23203832lfa.128.1567582796292; Wed, 04 Sep 2019 00:39:56 -0700 (PDT) Received: from localhost (host-217-214-150-141.mobileonline.telia.com. [217.214.150.141]) by smtp.gmail.com with ESMTPSA id j2sm3217576ljc.2.2019.09.04.00.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2019 00:39:55 -0700 (PDT) References: <86o9019mjr.fsf@gmail.com> <32018.1567542279@sss.pgh.pa.us> User-agent: mu4e 1.0; emacs 26.2 From: Malcolm Matalka To: Tom Lane Cc: pgsql-interfaces@lists.postgresql.org Subject: Re: Object IDs in Parse message In-reply-to: <32018.1567542279@sss.pgh.pa.us> Date: Wed, 04 Sep 2019 09:39:47 +0200 Message-ID: <86a7bk33y4.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --=-=-= Content-Type: text/plain Tom Lane writes: > Malcolm Matalka writes: >> Hello, I'm implementing my own pgsql client for fun and I'm trying to >> understand how to send a Parse message. The final parameter to Parse is >> a series of Int32s with the description: >> Specifies the object ID of the parameter data type. Placing a zero here >> is equivalent to leaving the type unspecified. > >> But where do I find the list of object IDs? > > SELECT oid, typname FROM pg_type; > >> If so, It's not clear how to express some things. For example there is >> a MONEYARRAYOID, but no MONEYOID. > > For historical reasons, the macro for money's OID is CASHOID. > There's no grandfathered symbol for money[], though, so that > gets a name constructed per standard rules (cf form_pg_type_symbol > in genbki.pl). > > However, I fail to see why a generic client would need to know that. > If you're hard-wiring OIDs into your code for anything beyond very > basic types like int4, you're probably doing it wrong. Remember Ok, it wasn't clear to me if and when I should pass this data in. I couldn't find any documentation for this translating to performance improvement, or addressing any possible errors due to ambiguity in types. In general, should an interface no pass that information in on a Parse? Is there a reason to do it? > that PG is an extensible system and you may be called on to handle > queries that deal with non-built-in types, so even if you had > code for everything appearing in pg_type_d.h, it wouldn't be > exhaustive. Better to look up type OIDs at runtime. In the case > of Parse messages, you likely want to let the backend resolve > the parameter types anyway, ie just send zeroes. > > regards, tom lane Thank you for the detailed response --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEQP2ClpgOfnguJZS++DiEc/oMrtcFAl1vakQACgkQ+DiEc/oM rtdF9AgAv8jZ+jXMZx6qCyFyhLgjSjKCVWKfs6c3cGvPeCRKH3arxRD9Rkxy1Jhj JUC43Bsf+id4JvKWMp415A73xn+0vgPxEs++RvQuYCraTh2sYpaA+qt1vT7m/NeZ OoJ9S1b0HBzeJWPqwnE3rlmb3sHrrPuJJ+ppB/+yXxLFVzCwH+Q5mXNvW1SHAlEb 6m3CROVQtEQByiJfdbYO613SwoE292TNh4wo/DoClaDyShH2J++GFXQ90Y9aTa6x HhB6OIDmf6yG9ZU8fpdFtYLc08gYo5DFG2hnV9ZRv3OqU+3MjtvGDPtMjXV5pn41 xLa8TJdKHYb6WG6RI7hOOipn+t6wAw== =HqdM -----END PGP SIGNATURE----- --=-=-=--