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 1pHRdC-00082G-98 for pgsql-odbc@arkaria.postgresql.org; Mon, 16 Jan 2023 15:42:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pHRdB-0003CY-4f for pgsql-odbc@arkaria.postgresql.org; Mon, 16 Jan 2023 15:42:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHRdA-0003CB-Fp for pgsql-odbc@lists.postgresql.org; Mon, 16 Jan 2023 15:42:40 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pHRd7-0000ep-EN for pgsql-odbc@lists.postgresql.org; Mon, 16 Jan 2023 15:42:39 +0000 Received: by mail-wm1-x342.google.com with SMTP id l41-20020a05600c1d2900b003daf986faaeso2552128wms.3 for ; Mon, 16 Jan 2023 07:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denodo.com; s=google; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=nqgJMDcWIa/4vK7zabB99NMQv1/XCKVOaseaTd0VqzA=; b=dQml+aZMgIv4J9cg7HhFLzkgsCp+T6a+XsBSCLY4sGaOssUWZp16BFyE0HdxjyJ7eE G8nWQs2aUac559F5C1Hu3OeFWCo8f+UeUZRynLzcffWMiQa0HgRrfcu2cNE4gIbBSNSA 0ijv0rrwFPXebYv+ddvHXXT7YLrTBEjNd8YG4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nqgJMDcWIa/4vK7zabB99NMQv1/XCKVOaseaTd0VqzA=; b=yTdIMyyVeYhmN6QWt/OFU+qRKY2u6zpLZG+OODMmzYw/qLQjQTFAuO6wb+E3nP0M75 EtEgOhqTBaPH0xTVJlX69kq4UZtBQeTd2eatl2xrEIJ2MXxolr8UVqQL/fv1Hbxq1Foc gjx/P6K9aLTje2HUabspu86AHaQSCnpyQ+cG9ZCb7T1n5bUFwzulDxDEciRzXd87ggJq kw1O8X5rSctgQxjcLZ7e/Hp60Cu4X+gpMusGP6BJ2NfhJidlKGqkS/Mysv/oHdSsWPrn ai7HBal4g8tYZRbVm8N/IZFMZqmH+bkiFYSx40sL05KXCdROn7p3T7AdSfJ+DELuIZRx 7zTA== X-Gm-Message-State: AFqh2kqyTKy5Lv4xoVxALXezBsd1irhJBSEEhbvOsFxpUv6ChIYERUkO WF4j556S2wa9DTPQn6/DGvtRk2pTh+BLC5lmZeikh4aG2ZTKyse3wOvNriyPAJII4d1XisR3OzK RYcOQ+5gXbOaiFfN6N5uclGERKrjns7j48ZxpZ+ncMjhYAX2DYjXISDI406N7R7Jt9XAuDqfGAn +DxIExp/l0 X-Google-Smtp-Source: AMrXdXvYG7MjbUvNZtLqIfC3qwYnRne33qPIe7J7cONGAqsXYveQVcNfLrgFe0jM4UsLR/HD+CIE2w== X-Received: by 2002:a1c:4b04:0:b0:3da:fc15:740c with SMTP id y4-20020a1c4b04000000b003dafc15740cmr3544112wma.19.1673883755602; Mon, 16 Jan 2023 07:42:35 -0800 (PST) Received: from [192.168.6.100] (75.182.27.77.dynamic.reverse-mundo-r.com. [77.27.182.75]) by smtp.gmail.com with ESMTPSA id i5-20020a05600c2d8500b003daf681d05dsm5144863wmg.26.2023.01.16.07.42.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Jan 2023 07:42:34 -0800 (PST) Content-Type: multipart/alternative; boundary="------------e5Wv2QXlSl7OM0PnNq6R0NR2" Message-ID: Date: Mon, 16 Jan 2023 16:42:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: pgsql-odbc@lists.postgresql.org From: =?UTF-8?Q?Jacobo_S=c3=a1nchez_L=c3=b3pez?= Subject: Substitution of convert function "{fn CONVERT(1, SQL_BIGINT)}" to text litreral '1' List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------e5Wv2QXlSl7OM0PnNq6R0NR2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi     I am doing some tests and found that when using a query with the convert function like SELECT SUM({fn CONVERT(1, SQL_BIGINT)})     It gets translated to SELECT SUM('1')     Which fails due to the aggregation function receiving a text literal instead of a number.     I have narrowed down to this line in convert.c (https://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=convert.c;h=d94fdb685df0a3430a13650f5140bb3bbb1d6272;hb=HEAD#l5744) deciding to add the quotes: 5743 else if (isdigit((unsigned char) *pptr)) 5744                     add_quote = TRUE;     How expected is that convert function to produce a text literal which makes the query to fail?     The simpliest way to reproduce it I found is with a python script using a DSN called PostgreSQL35W (tested with version 13.02.0000): importpyodbc query= "SELECT SUM({fn CONVERT(1, SQL_INTEGER)})" connection= pyodbc.connect('DSN=PostgreSQL35W',autocommit=True) cursor= connection.cursor() cursor.execute(query) forrowincursor.fetchall(): print(row) Best regards, Jacobo --------------e5Wv2QXlSl7OM0PnNq6R0NR2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi

    I am doing some tests and found that when using a query with the convert function like

    SELECT SUM({fn CONVERT(1, SQL_BIGINT)})

    It gets translated to

   SELECT SUM('1')

    Which fails due to the aggregation function receiving a text literal instead of a number.

    I have narrowed down to this line in convert.c (https://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=convert.c;h=d94fdb685df0a3430a13650f5140bb3bbb1d6272;hb=HEAD#l5744) deciding to add the quotes:

5743                 else if (isdigit((unsigned char) *pptr))
5744                     add_quote = TRUE;

    How expected is that convert function to produce a text literal which makes the query to fail?


    The simpliest way to reproduce it I found is with a python script using a DSN called PostgreSQL35W (tested with version 13.02.0000):


import pyodbc
query = "SELECT SUM({fn CONVERT(1, SQL_INTEGER)})"
connection = pyodbc.connect('DSN=PostgreSQL35W',autocommit=True)
cursor = connection.cursor()
cursor.execute(query)
for row in cursor.fetchall():
    print(row)


Best regards,

Jacobo


--------------e5Wv2QXlSl7OM0PnNq6R0NR2--