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.96) (envelope-from ) id 1vz07E-000blP-0l for pgsql-general@arkaria.postgresql.org; Sat, 07 Mar 2026 22:27:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vz07B-009mVW-26 for pgsql-general@arkaria.postgresql.org; Sat, 07 Mar 2026 22:27:18 +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.96) (envelope-from ) id 1vz07B-009mVN-0y for pgsql-general@lists.postgresql.org; Sat, 07 Mar 2026 22:27:17 +0000 Received: from mail-oi1-x234.google.com ([2607:f8b0:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vz078-00000001P3G-3czo for pgsql-general@lists.postgresql.org; Sat, 07 Mar 2026 22:27:17 +0000 Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-466ec4c6852so457526b6e.3 for ; Sat, 07 Mar 2026 14:27:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772922432; cv=none; d=google.com; s=arc-20240605; b=QVzM5vn1hjntDxjpUbTA38N/tIgiZC8DGAphp4YFA+Mj675ekkBvFkwyBGZSZZQpkU lcGNyEQmCRTVwHnxsNJGU6VqKObogYXaTxI5oSIg3eHEgyQvDT053zwQ6a1j2j84p3wu EA96RdqpQstrBwzc+P/w+88TogAikGmfkLrJhwGjEUvid9I47u0BDLX7s1H3pLX7t2sh oO0u2oYNm3P7RGArh/6wYQz0XgYlOMsd+C+lzLmchpL11urpppk1UNLJUHYnydfJK1N8 Q4/MPXP/NikXuxl7QvWb4quBgf02J1svX1oMzigZVNaGpqt0z+K/dHhlTakqYy2xRldx cujQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=fwc+Qotf46bnEbla/va1t+yuxnD/7tYZuU4izLvnONk=; fh=IM0/es+T9zLhNBTZg/IdFsItEIcBxxEvdq668WyYVkc=; b=fnWa4k1djASw5oVbFo5QY/qbsdO1VntAZO19ECRqzw0xCeXi89cHOCd9G4+dxV29QD s3+y2LnNTqYsTGRECNZZJE0uGbrDhTTRctqJ1d7lr2l5k7Gm/LHjUzyueaY+ty27cxO5 pkeesFMAhj71JZ9I7cz4vP2FmoKdYsKZEvv93qpNl47Nr2kt2xwpxwbLqCqoo7Lo5TTS jvIOtoukkx4bCSF7a9OHQJZd8LK0ygp7+31RvQ64BabKNSzlU+qoWkgt2VP0wwiZ9C/U QQ7O2k75ozZAMuUzW5nhCoFfwRytolr/Gpa/zZPi2r2qBWjimE9Xb+q6mwW2Wsyl/euD 19Lw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772922432; x=1773527232; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fwc+Qotf46bnEbla/va1t+yuxnD/7tYZuU4izLvnONk=; b=FN2qGfSdW3mpM2t4VsOnSObM55vr9gb5Z1JiB5M247/rYiswo2kTWX+2AcMtcTe+4r yyGq8go6XcZFmgL55kFAg9cRU8kX3WYjXU5Kf/xKzXbKkBcu6/8a6mMzwmtwfDDazqY4 /ND+7g9pHE89gCA6yknXdcfxPcC2wVh6LKbGWgvhtVKY3YcL4DZv0xjK/IS7RNwC42Jf mPzw9QjeGS/sViogzFQHl/sHc/vTi1dUCJd+SqxiFF+kkOSIiCfOkh4K+JUKMb25/pcd eUuSmiJBWc04LE2NYfn1LuWNEBjnbobb6dLhhWPMW3FTU6APUSoGLZeS7CS3TGAIs9He Uw6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772922432; x=1773527232; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fwc+Qotf46bnEbla/va1t+yuxnD/7tYZuU4izLvnONk=; b=MPKa8J6+q0OKJUJLQbUavm11hFm+2YaykNA3YYgpi4uFvbaavVO4nMB3/OpdYXeyP1 GgExUPK8eiTgN0GanUF6pc8JKyXv8HWqVBHQ+GQWXCMrT/JG6EyLFCDQRGYj/nS5lfVC 7DXpVBk7BWCwgL3IYDpgZybMVYz/QrTS0CBTFzH4FMAG5ceeXJTfK4xlrOGzR24nqVTM vzZNMEa8ItbL7MK//pcsIP/J4gg2eLblRqbIhqOntxf9CzA25/ynov5xJp3vIdLbUvr4 WUenEd0NKzAMnE5ITVvPkFDINIe3tstdpiKQfHenLg4hiTSE4M4aiCgirAoLuvD5YNcG 2zbA== X-Forwarded-Encrypted: i=1; AJvYcCVr4xy5uUUu8qXM6kn4p1JuD4PVROTya7bajP6hPzuTDO2So5+5KQYkIfj91CNSHC881NiNAqaMDzCxPZXF@lists.postgresql.org X-Gm-Message-State: AOJu0Yx/eiyo0M8DgedvhZX7xUeLqagZshGdcDm3VsdILOtlBKMlP+wF DWiqSM7dlso5DUO4Zs4Iy0rIVpBLYAZIM0GVSThEH8jiKQ3GAZAEwcS060dxVx9WTTj0eEuliRM t0HS2zfxx764HYGcU5uSmkrYPan8s70k= X-Gm-Gg: ATEYQzzWQhJUH8vxt2GFNqQN9EIaBUoO7MoVJlSui3BxeB6jupCtR3PklfEUMDjGyCv 6H1kI+QtVrAn1td7OInm25//p4QgcUqGx/wc1KPFoj8Bx0IPKbOawWc9MP1OsKsn3UnQgPDPqu8 F2bxcr9+3d4VL0jRxaCwS6nJsaNTU3LWXdoAqgN/gFIMfCiHg+0tKwfeqc8dIJGM4hbLZMXuXs0 Qbsn5X+ga/7iUCf1BroPVUa7ka7wneOUITWq9wIL83cLD3eX4iTVq2VNrB+U3xTx8Ykz4A0I6Lq C2RNt08= X-Received: by 2002:a05:6808:15a2:b0:464:8533:e32f with SMTP id 5614622812f47-466dcb3f8e5mr3706002b6e.35.1772922432196; Sat, 07 Mar 2026 14:27:12 -0800 (PST) MIME-Version: 1.0 References: <8f73ec0b-8f68-4f87-badc-a86939a211e1@aklaver.com> In-Reply-To: From: "David G. Johnston" Date: Sat, 7 Mar 2026 15:26:35 -0700 X-Gm-Features: AaiRm50BOpnaem-uJsHztt274zVoRJV_dGsdABKA2vAVW3AXKET36PWqmgBNhPk Message-ID: Subject: Re: How to properly use TRIM()? To: Igor Korot Cc: Adrian Klaver , Rob Sargent , "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000c91471064c76ab47" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c91471064c76ab47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 7, 2026 at 2:46=E2=80=AFPM Igor Korot wrot= e: > Hi, Adrian, > > On Sat, Mar 7, 2026 at 3:29=E2=80=AFPM Adrian Klaver > wrote: > > > > On 3/7/26 12:46 PM, Igor Korot wrote: > > > Hi, David, > > > > > > On Sat, Mar 7, 2026 at 12:03=E2=80=AFPM David G. Johnston > > > > > wrote: > > > > > > On Sat, Mar 7, 2026 at 12:58=E2=80=AFPM Igor Korot > > > wrote: > > > > > > So I started looking for a way to return SQL_NO_DATA > > > on that 4th column... > > > > > > > > > Doesn't "No Data" refer to the result set as a whole, not > individual > > > columns? I'd assume NULL is detected some other way. > > > > > > > > > No, I think it=E2=80=99s column based. > > > > 1) My knowledge of ODBC is limited. > > > > 2) This: > > > > > https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/return-c= odes-odbc?view=3Dsql-server-ver17 > > > > "SQL_NO_DATA No more data was available. The application calls > > SQLGetDiagRec or SQLGetDiagField to retrieve additional information. On= e > > or more driver-defined status records in class 02xxx may be returned. > > Note: In ODBC 2.x, this return code was named SQL_NO_DATA_FOUND." > > > > would seem to indicate that David Johnston is correct: > > From the SQLGetData() ODBC documentation > ( > https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetdata-fu= nction?view=3Dsql-server-ver17 > ): > > [quote] > When it returns the last part of the data, SQLGetData returns > SQL_SUCCESS. Neither SQL_NO_TOTAL nor zero can be returned on the last > valid call to retrieve data from a column, because the application > would then have no way of knowing how much of the data in the > application buffer is valid. If SQLGetData is called after this, it > returns SQL_NO_DATA. For more information, see the next section, > "Retrieving Data with SQLGetData." > [/quote] > > However it looks like the driver does not behave as expected. > > It keeps returning SQL_SUCCESS continuously... > > Or am I misinterpreting the docs? > > Ok, you are indeed performing an iteration of SQLGetData that does return SQL_NO_DATA when you've exhausted the contents of the field being retrieved= . You still need to check ind[3] for: https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetdata-func= tion?view=3Dsql-server-ver17#retrieving-data-with-sqlgetdata Step 2 I have no idea why you would end up in an infinite loop there though. I suppose maybe step 2's lack of describing the flow when the data is null means you need to break out of the loop manually after dealing with the null value in some manner. David J. --000000000000c91471064c76ab47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 7, 2026 at 2:46=E2=80=AFPM Igor Korot <ikorot01@gmail.com> wrote:<= /div>
Hi, Adrian,

On Sat, Mar 7, 2026 at 3:29=E2=80=AFPM Adrian Klaver <adrian.klaver@aklaver.com&= gt; wrote:
>
> On 3/7/26 12:46 PM, Igor Korot wrote:
> > Hi, David,
> >
> > On Sat, Mar 7, 2026 at 12:03=E2=80=AFPM David G. Johnston
> > <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wr= ote:
> >
> >=C2=A0 =C2=A0 =C2=A0On Sat, Mar 7, 2026 at 12:58=E2=80=AFPM Igor K= orot <ikorot01@g= mail.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:ikorot01@gmail.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So I started looking for a way t= o return SQL_NO_DATA
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on that 4th column...
> >
> >
> >=C2=A0 =C2=A0 =C2=A0Doesn't "No Data" refer to the r= esult set as a whole, not individual
> >=C2=A0 =C2=A0 =C2=A0columns?=C2=A0 I'd assume NULL is detected= some other way.
> >
> >
> > No, I think it=E2=80=99s column based.
>
> 1) My knowledge of ODBC is limited.
>
> 2) This:
>
> https://learn.microsoft.com/en-us/sql/odbc/reference/develop-ap= p/return-codes-odbc?view=3Dsql-server-ver17
>
> "SQL_NO_DATA=C2=A0 =C2=A0 No more data was available. The applica= tion calls
> SQLGetDiagRec or SQLGetDiagField to retrieve additional information. O= ne
> or more driver-defined status records in class 02xxx may be returned.<= br> > Note: In ODBC 2.x, this return code was named SQL_NO_DATA_FOUND."=
>
> would seem to indicate that David Johnston is correct:

From the SQLGetData() ODBC documentation
(https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetdata-= function?view=3Dsql-server-ver17):

[quote]
When it returns the last part of the data, SQLGetData returns
SQL_SUCCESS. Neither SQL_NO_TOTAL nor zero can be returned on the last
valid call to retrieve data from a column, because the application
would then have no way of knowing how much of the data in the
application buffer is valid. If SQLGetData is called after this, it
returns SQL_NO_DATA. For more information, see the next section,
"Retrieving Data with SQLGetData."
[/quote]

However it looks like the driver does not behave as expected.

It keeps returning SQL_SUCCESS continuously...

Or am I misinterpreting the docs?


<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Ok, you are indeed performing an iteration of SQLGetData that does return= SQL_NO_DATA when you've exhausted the contents of the field being retr= ieved.

You still need to check ind[3] for:=C2=A0
=
https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetdata-fun= ction?view=3Dsql-server-ver17#retrieving-data-with-sqlgetdata
S= tep 2

I have no idea why you would end up in an infini= te loop there though.=C2=A0 I suppose maybe step 2's lack of describing= the flow when the data is null means you need to break out of the loop man= ually after dealing with the null value in some manner.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">David J.



--000000000000c91471064c76ab47--