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 1i5S1B-0005NG-QR for pgsql-interfaces@arkaria.postgresql.org; Wed, 04 Sep 2019 09:56:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i5S1A-0002B8-De for pgsql-interfaces@arkaria.postgresql.org; Wed, 04 Sep 2019 09:56:00 +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 1i5S1A-00026C-5R for pgsql-interfaces@lists.postgresql.org; Wed, 04 Sep 2019 09:56:00 +0000 Received: from mail-qt1-f172.google.com ([209.85.160.172]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i5S16-0002iW-P8 for pgsql-interfaces@lists.postgresql.org; Wed, 04 Sep 2019 09:55:59 +0000 Received: by mail-qt1-f172.google.com with SMTP id o12so12087417qtf.3 for ; Wed, 04 Sep 2019 02:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v8DcysjPELuznxt6+I66n9J+EWqSFOA/sQWHw8T9PgU=; b=rDCjEfVK4ucFxWosp/QyZUakBpTarVRboUlu8x6R3PFVL5Tfq9gXGmgesgD02+PL3y XVYz+mc2Zoi16PKbir7eFeBfZfahkOAsszK35COv5ysfVMxG2Lun5FeVy/Z+35wa06ZX a6JadLKrLpOCwfpN1M/4Oh5ukHDK8VpCDaJnP1OU2Z30n1/BouhGoTcs5HFIIqN7PT7M 6WlnkpOgZwzi3cchX7ZL7KoG4puCLjXkT/lTPKzEbyZTbG4oUoHD5+7qj7INAJurQpue niDZDtqNITFCWox9ySo9TRPq+GGPP7k6qWqM+2iYIsqAF+hI2qX3gXvtujfHVTq1fxIx +Z3Q== X-Gm-Message-State: APjAAAWetKmOLIVe7BzeDoK0O857WbHYq2e7PAH/2wNxMYs3JGCpTP+B eHIan949P0kcd5bv+HKIHOTj3Wx8e9cSrwmH/6Z73je5 X-Google-Smtp-Source: APXvYqyAMd4M7El1wN93rJKPA3YEz76swIQEQBkKgBdsW0chJcnJT5fgO/gnq+uZ6I7wGodLns2X+lmakxVVp7CMsJ4= X-Received: by 2002:a63:5b23:: with SMTP id p35mr33540923pgb.366.1567590572453; Wed, 04 Sep 2019 02:49:32 -0700 (PDT) MIME-Version: 1.0 References: <86o9019mjr.fsf@gmail.com> <32018.1567542279@sss.pgh.pa.us> <86a7bk33y4.fsf@gmail.com> In-Reply-To: <86a7bk33y4.fsf@gmail.com> From: Dave Cramer Date: Wed, 4 Sep 2019 05:49:21 -0400 Message-ID: Subject: Re: Object IDs in Parse message To: Malcolm Matalka Cc: Tom Lane , pgsql-interfaces@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003974780591b71fc3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000003974780591b71fc3 Content-Type: text/plain; charset="UTF-8" On Wed, 4 Sep 2019 at 03:45, Malcolm Matalka wrote: > > 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? > Yes, if you ever decide to use binary mode for the parameters and the results then you need to know the type The jdbc driver and the .net driver both do this. Dave --0000000000003974780591b71fc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 4 Sep 2019 at 03:45, Malcolm = Matalka <mmatalka@gmail.com>= ; wrote:

Tom Lane <tgl@sss= .pgh.pa.us> writes:

> Malcolm Matalka <mmatalka@gmail.com> writes:
>> Hello, I'm implementing my own pgsql client for fun and I'= m trying to
>> understand how to send a Parse message.=C2=A0 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.=C2=A0 For ex= ample 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 g= enbki.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.=C2=A0 Remem= ber

Ok, it wasn't clear to me if and when I should pass this data in.=C2=A0= I
couldn't find any documentation for this translating to performance
improvement, or addressing any possible errors due to ambiguity in
types.=C2=A0 In general, should an interface no pass that information in on= a
Parse?=C2=A0 Is there a reason to do it?

Yes, if you ever decide to use binary mode for the parameters and the res= ults then you need to know the type
The jdbc driver and the .net = driver both do this.

Dave
--0000000000003974780591b71fc3--