Thread

  1. Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-14T07:09:04Z

    Hi, ALL,
    Have one weird question ;-)
    
    When I connect with ODBC and call SQLPrimaryKey() the function returns
    all fields including
    "included" fields.
    
    However running libpq and trying to get the table info with:
    
    [quote]
        L"SELECT DISTINCT column_name, data_type,
    character_maximum_length, character_octet_length, numeric_precision,
    numeric_precision_radix, numeric_scale, is_nullable, column_default,
    CASE WHEN column_name IN (SELECT ccu.column_name FROM
    information_schema.constraint_column_usage ccu,
    information_schema.table_constraints tc WHERE ccu.constraint_name =
    tc.constraint_name AND tc.constraint_type = 'PRIMARY KEY' AND
    ccu.table_name = $2) THEN 'YES' ELSE 'NO' END AS is_pk,
    ordinal_position FROM information_schema.columns col,
    information_schema.table_constraints tc WHERE tc.table_schema =
    col.table_schema AND tc.table_name = col.table_name AND
    col.table_schema = $1 AND col.table_name = $2 ORDER BY
    ordinal_position;";
    [/quote]
    
    I'm getting only direct PK fields.
    
    I presume that libpq is correct and the ODBC driver is the one that
    needs to be fixed.
    
    Just wanted to ask this list before going to complain to the ODBC list... ;-)
    
    Thank you.
    
    
    
    
  2. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-14T07:12:42Z

    Below is the version info I use on this machine:
    
    Calculating dependencies... done!
    Dependency resolution took 53.38 s (backtrack: 0/20).
    
    [ebuild   R    ] dev-db/postgresql-16.2:16::gentoo  USE="icu lz4 nls
    pam readline ssl xml zlib zstd -debug -doc -kerberos -ldap -llvm -perl
    -python (-selinux) -server* -static-libs -systemd -tcl -uuid"
    PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12" 0 KiB
    [ebuild   R    ] dev-db/psqlodbc-11.01.0000::gentoo  USE="ssl -doc
    -iodbc -threads" 0 KiB
    
    Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB
    WaylandGnome /home/igor/dbhandler/Debug #
    
    Thank you.
    
    
    On Sat, Mar 14, 2026 at 2:09 AM Igor Korot <ikorot01@gmail.com> wrote:
    >
    > Hi, ALL,
    > Have one weird question ;-)
    >
    > When I connect with ODBC and call SQLPrimaryKey() the function returns
    > all fields including
    > "included" fields.
    >
    > However running libpq and trying to get the table info with:
    >
    > [quote]
    >     L"SELECT DISTINCT column_name, data_type,
    > character_maximum_length, character_octet_length, numeric_precision,
    > numeric_precision_radix, numeric_scale, is_nullable, column_default,
    > CASE WHEN column_name IN (SELECT ccu.column_name FROM
    > information_schema.constraint_column_usage ccu,
    > information_schema.table_constraints tc WHERE ccu.constraint_name =
    > tc.constraint_name AND tc.constraint_type = 'PRIMARY KEY' AND
    > ccu.table_name = $2) THEN 'YES' ELSE 'NO' END AS is_pk,
    > ordinal_position FROM information_schema.columns col,
    > information_schema.table_constraints tc WHERE tc.table_schema =
    > col.table_schema AND tc.table_name = col.table_name AND
    > col.table_schema = $1 AND col.table_name = $2 ORDER BY
    > ordinal_position;";
    > [/quote]
    >
    > I'm getting only direct PK fields.
    >
    > I presume that libpq is correct and the ODBC driver is the one that
    > needs to be fixed.
    >
    > Just wanted to ask this list before going to complain to the ODBC list... ;-)
    >
    > Thank you.
    
    
    
    
  3. Re: Does included columns part of the PK

    David G. Johnston <david.g.johnston@gmail.com> — 2026-03-14T15:07:37Z

    On Saturday, March 14, 2026, Igor Korot <ikorot01@gmail.com> wrote:
    
    >
    > I presume that libpq is correct and the ODBC driver is the one that
    > needs to be fixed.
    >
    
    Odbc does seem to be in the wrong here, yes.
    
    David J.
    
  4. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-14T15:25:08Z

    On 3/14/26 12:09 AM, Igor Korot wrote:
    > Hi, ALL,
    > Have one weird question ;-)
    > 
    > When I connect with ODBC and call SQLPrimaryKey() the function returns
    
    Are you actually using the SQLPrimaryKeys(), not SQLPrimaryKey()?
    
    > all fields including
    > "included" fields.
    
    Define 'included' fields.
    
    > I'm getting only direct PK fields.
    
    Define direct PK fields.
    
    > 
    > I presume that libpq is correct and the ODBC driver is the one that
    > needs to be fixed.
    
    Returning the actual results from each case would help.
    
    Have you cranked up the logging on the Postgres server to see what query 
    ODBC is using?
    
    > 
    > Just wanted to ask this list before going to complain to the ODBC list... ;-)
    > 
    > Thank you.
    > 
    > 
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  5. Re: Does included columns part of the PK

    David G. Johnston <david.g.johnston@gmail.com> — 2026-03-14T15:51:24Z

    On Saturday, March 14, 2026, Adrian Klaver <adrian.klaver@aklaver.com>
    wrote:
    
    > On 3/14/26 12:09 AM, Igor Korot wrote:
    >
    >> Hi, ALL,
    >> Have one weird question ;-)
    >>
    >> When I connect with ODBC and call SQLPrimaryKey() the function returns
    >>
    >
    > Are you actually using the SQLPrimaryKeys(), not SQLPrimaryKey()?
    >
    > all fields including
    >> "included" fields.
    >>
    >
    > Define 'included' fields.
    >
    
    They are referring to the unique index that backs the PK constraint.
    
    David J.
    
  6. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-14T16:56:55Z

    Hi,
    
    On Sat, Mar 14, 2026 at 8:51 AM David G. Johnston <
    david.g.johnston@gmail.com> wrote:
    
    > On Saturday, March 14, 2026, Adrian Klaver <adrian.klaver@aklaver.com>
    > wrote:
    >
    >> On 3/14/26 12:09 AM, Igor Korot wrote:
    >>
    >>> Hi, ALL,
    >>> Have one weird question ;-)
    >>>
    >>> When I connect with ODBC and call SQLPrimaryKey() the function returns
    >>>
    >>
    >> Are you actually using the SQLPrimaryKeys(), not SQLPrimaryKey()?
    >>
    >> all fields including
    >>> "included" fields.
    >>>
    >>
    >> Define 'included' fields.
    >>
    >
    > They are referring to the unique index that backs the PK constraint.
    >
    
    Not “they” - “He”. 😊
    
    And yes - that’s what I’m referring to.
    
    Thank you.
    
    
    > David J.
    >
    
  7. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-14T23:30:19Z

    On 3/14/26 9:56 AM, Igor Korot wrote:
    > Hi,
    > 
    > On Sat, Mar 14, 2026 at 8:51 AM David G. Johnston 
    > <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
    > 
    >     On Saturday, March 14, 2026, Adrian Klaver
    >     <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
    > 
    >         On 3/14/26 12:09 AM, Igor Korot wrote:
    > 
    >             Hi, ALL,
    >             Have one weird question ;-)
    > 
    >             When I connect with ODBC and call SQLPrimaryKey() the
    >             function returns
    > 
    > 
    >         Are you actually using the SQLPrimaryKeys(), not SQLPrimaryKey()?
    > 
    >             all fields including
    >             "included" fields.
    > 
    > 
    >         Define 'included' fields.
    > 
    > 
    >     They are referring to the unique index that backs the PK constraint.
    > 
    > 
    > Not “they” - “He”. 😊
    > 
    > And yes - that’s what I’m referring to.
    
     From here:
    
    
    https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=functions-sqlprimarykeys-get-primary-key-columns-table:
    
    1	TABLE_CAT	VARCHAR(128)	This is always null.
    2	TABLE_SCHEM	VARCHAR(128)	The name of the schema containing TABLE_NAME.
    3	TABLE_NAME	VARCHAR(128) NOT NULL	Name of the specified table.
    4	COLUMN_NAME	VARCHAR(128) NOT NULL	Primary key column name.
    5	KEY_SEQ	SMALLINT NOT NULL	Column sequence number in the primary key, 
    starting with 1.
    6	PK_NAME	VARCHAR(128)	Primary key identifier. Contains a null value if 
    not applicable to the data
    
    
     From here:
    
    https://github.com/postgresql-interfaces/psqlodbc/blob/main/info.c
    
    At line 4035 in SQLPrimaryKeys()
    
    For case 1
    
    /*
    				 * Simplified query to remove assumptions about number of
    				 * possible index columns. Courtesy of Tom Lane - thomas
    				 * 2000-03-21
    				 */
    
    [...]
    
    "select ta.attname, ia.attnum, ic.relname, n.nspname, tc.relname"
    					" from pg_catalog.pg_attribute ta ... "
    
    
    case 2
    
    select ta.attname, ia.attnum, ic.relname, n.nspname, NULL"
    					" from pg_catalog.pg_attribute ta, ..."
    
    If I am following correctly then:
    
    attname = column_name
    attnum = key_seq
    ic.relname = pk_name
    nspname = table_schem
    tc.relname = table_name
    
    
    So how are using it in your code and what are the actual results?
    
    Also what is showing up in the Postgres logs?
    
    > 
    > Thank you.
    > 
    > 
    >     David J.
    > 
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  8. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-15T06:24:38Z

    Hi, Adrian,
    
    On Sat, Mar 14, 2026 at 6:30 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/14/26 9:56 AM, Igor Korot wrote:
    > > Hi,
    > >
    > > On Sat, Mar 14, 2026 at 8:51 AM David G. Johnston
    > > <david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com>> wrote:
    > >
    > >     On Saturday, March 14, 2026, Adrian Klaver
    > >     <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote:
    > >
    > >         On 3/14/26 12:09 AM, Igor Korot wrote:
    > >
    > >             Hi, ALL,
    > >             Have one weird question ;-)
    > >
    > >             When I connect with ODBC and call SQLPrimaryKey() the
    > >             function returns
    > >
    > >
    > >         Are you actually using the SQLPrimaryKeys(), not SQLPrimaryKey()?
    > >
    > >             all fields including
    > >             "included" fields.
    > >
    > >
    > >         Define 'included' fields.
    > >
    > >
    > >     They are referring to the unique index that backs the PK constraint.
    > >
    > >
    > > Not “they” - “He”. 😊
    > >
    > > And yes - that’s what I’m referring to.
    >
    >  From here:
    >
    >
    > https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=functions-sqlprimarykeys-get-primary-key-columns-table:
    >
    > 1       TABLE_CAT       VARCHAR(128)    This is always null.
    > 2       TABLE_SCHEM     VARCHAR(128)    The name of the schema containing TABLE_NAME.
    > 3       TABLE_NAME      VARCHAR(128) NOT NULL   Name of the specified table.
    > 4       COLUMN_NAME     VARCHAR(128) NOT NULL   Primary key column name.
    > 5       KEY_SEQ SMALLINT NOT NULL       Column sequence number in the primary key,
    > starting with 1.
    > 6       PK_NAME VARCHAR(128)    Primary key identifier. Contains a null value if
    > not applicable to the data
    >
    >
    
    Lets start with the beginning:
    
    draft=# CREATE TABLE leagues_new(id serial, name varchar(100),
    drafttype smallint, scoringtype smallint, roundvalues smallint,
    leaguetype char(5), salary integer, benchplayers smallint, primary
    key(id) INCLUDE (drafttype, scoringtype) WITH( fillfactor = 50,
    deduplicate_items = OFF ));
    CREATE TABLE
    draft=#
    
    
    >  From here:
    >
    > https://github.com/postgresql-interfaces/psqlodbc/blob/main/info.c
    >
    > At line 4035 in SQLPrimaryKeys()
    >
    > For case 1
    >
    > /*
    >                                  * Simplified query to remove assumptions about number of
    >                                  * possible index columns. Courtesy of Tom Lane - thomas
    >                                  * 2000-03-21
    >                                  */
    >
    > [...]
    >
    > "select ta.attname, ia.attnum, ic.relname, n.nspname, tc.relname"
    >                                         " from pg_catalog.pg_attribute ta ... "
    >
    >
    > case 2
    >
    > select ta.attname, ia.attnum, ic.relname, n.nspname, NULL"
    >                                         " from pg_catalog.pg_attribute ta, ..."
    >
    > If I am following correctly then:
    >
    > attname = column_name
    > attnum = key_seq
    > ic.relname = pk_name
    > nspname = table_schem
    > tc.relname = table_name
    >
    >
    > So how are using it in your code and what are the actual results?
    >
    > Also what is showing up in the Postgres logs?
    >
    > >
    > > Thank you.
    > >
    > >
    > >     David J.
    > >
    >
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  9. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-15T15:34:13Z

    On 3/14/26 11:24 PM, Igor Korot wrote:
    > Hi, Adrian,
    
    > 
    > Lets start with the beginning:
    > 
    > draft=# CREATE TABLE leagues_new(id serial, name varchar(100),
    > drafttype smallint, scoringtype smallint, roundvalues smallint,
    > leaguetype char(5), salary integer, benchplayers smallint, primary
    > key(id) INCLUDE (drafttype, scoringtype) WITH( fillfactor = 50,
    > deduplicate_items = OFF ));
    > CREATE TABLE
    > draft=#
    
    I think the above is for this thread:
    
    https://www.postgresql.org/message-id/CA%2BFnnTyGEM-1mwxKPbwFTOodf%2BYUX%3DTxTmBPY5S%3DYh1h%3DoVY9A%40mail.gmail.com
    
    
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  10. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-16T01:23:57Z

    Hi, Adrian,
    
    Here is the log file from running in ODBC mode: https://bpa.st/Z2DWG
    
    Thank you.
    
    On Sun, Mar 15, 2026 at 10:34 AM Adrian Klaver
    <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/14/26 11:24 PM, Igor Korot wrote:
    > > Hi, Adrian,
    >
    > >
    > > Lets start with the beginning:
    > >
    > > draft=# CREATE TABLE leagues_new(id serial, name varchar(100),
    > > drafttype smallint, scoringtype smallint, roundvalues smallint,
    > > leaguetype char(5), salary integer, benchplayers smallint, primary
    > > key(id) INCLUDE (drafttype, scoringtype) WITH( fillfactor = 50,
    > > deduplicate_items = OFF ));
    > > CREATE TABLE
    > > draft=#
    >
    > I think the above is for this thread:
    >
    > https://www.postgresql.org/message-id/CA%2BFnnTyGEM-1mwxKPbwFTOodf%2BYUX%3DTxTmBPY5S%3DYh1h%3DoVY9A%40mail.gmail.com
    >
    >
    >
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  11. Re: Does included columns part of the PK

    Greg Sabino Mullane <htamfids@gmail.com> — 2026-03-16T13:53:11Z

    Please don't send links to external sites. Since I've already clicked on
    it, I'll put it here for the archives as an attachment.
    
  12. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-16T15:03:42Z

    On 3/15/26 6:23 PM, Igor Korot wrote:
    > Hi, Adrian,
    > 
    > Here is the log file from running in ODBC mode: https://bpa.st/Z2DWG
    
    I have no idea what this is trying to show?
    
    Is it referring to the thread  I linked to below:
    
    "CREATE TABLE fails"
    
    or this thread?
    
    In any case what actions on the client action where done and how did 
    they not match expectations?
    
    If this was really about the "CREATE TABLE fails" thread it needs to go 
    back there.
    
    As to this thread go back to:
    
    https://www.postgresql.org/message-id/3547f40b-08b9-4d0c-bba8-f1c26d0bf09d%40aklaver.com
    
    and provide the information requested.
    
    > 
    > Thank you.
    > 
    > On Sun, Mar 15, 2026 at 10:34 AM Adrian Klaver
    > <adrian.klaver@aklaver.com> wrote:
    >>
    >> On 3/14/26 11:24 PM, Igor Korot wrote:
    >>> Hi, Adrian,
    >>
    >>>
    >>> Lets start with the beginning:
    >>>
    >>> draft=# CREATE TABLE leagues_new(id serial, name varchar(100),
    >>> drafttype smallint, scoringtype smallint, roundvalues smallint,
    >>> leaguetype char(5), salary integer, benchplayers smallint, primary
    >>> key(id) INCLUDE (drafttype, scoringtype) WITH( fillfactor = 50,
    >>> deduplicate_items = OFF ));
    >>> CREATE TABLE
    >>> draft=#
    >>
    >> I think the above is for this thread:
    >>
    >> https://www.postgresql.org/message-id/CA%2BFnnTyGEM-1mwxKPbwFTOodf%2BYUX%3DTxTmBPY5S%3DYh1h%3DoVY9A%40mail.gmail.com
    >>
    >>
    >>
    >>
    >> --
    >> Adrian Klaver
    >> adrian.klaver@aklaver.com
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  13. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-16T18:43:13Z

    Thx, Greg.
    
    
    On Mon, Mar 16, 2026, 6:53 AM Greg Sabino Mullane <htamfids@gmail.com>
    wrote:
    
    > Please don't send links to external sites. Since I've already clicked on
    > it, I'll put it here for the archives as an attachment.
    >
    >
    >
    
  14. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-16T21:27:05Z

    On 3/16/26 11:44 AM, Igor Korot wrote:
    Reply to list also
    Ccing list
    > Adrian,
    > 
    > On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com 
    > <mailto:adrian.klaver@aklaver.com>> wrote:
    > 
    >     On 3/15/26 6:23 PM, Igor Korot wrote:
    >      > Hi, Adrian,
    >      >
    >      > Here is the log file from running in ODBC mode: https://bpa.st/
    >     Z2DWG <https://bpa.st/Z2DWG>
    > 
    >     I have no idea what this is trying to show?
    > 
    > 
    > Didn't you ask for a log file from running ODBC?
    
    No.
    
     From here:
    
    https://www.postgresql.org/message-id/3547f40b-08b9-4d0c-bba8-f1c26d0bf09d%40aklaver.com
    
    "
    So how are using it in your code and what are the actual results?
    
    
    Also what is showing up in the Postgres logs?
    "
    
    While you are it specify what ODBC driver you are using and what what 
    version.
    
    > 
    > Thank you.
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  15. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-16T21:30:32Z

    On 3/16/26 11:47 AM, Igor Korot wrote:
    
    Reply to list also.
    Ccing list.
    > Adrian,
    > 
    > 
    > 
    > On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com 
    > <mailto:adrian.klaver@aklaver.com>> wrote:
    > 
    >     On 3/15/26 6:23 PM, Igor Korot wrote:
    >      > Hi, Adrian,
    >      >
    >      > Here is the log file from running in ODBC mode: https://bpa.st/
    >     Z2DWG <https://bpa.st/Z2DWG>
    > 
    >     I have no idea what this is trying to show?
    > 
    > 
    > The log shows ODBC connection and then at the end - call to 
    > SQLPrimaryKeys().
    
    Where?
    
    I don't see that in either the link you posted or the text file Greg 
    sent to the list.
    
    > 
    > If you run it against the table I posted above, you will get 3 fields.  
    > Whereas it should be just one.
    
    Again, run it how?
    
    > 
    > Thank you.
    > 
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  16. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-16T21:40:20Z

    On 3/16/26 2:30 PM, Adrian Klaver wrote:
    > On 3/16/26 11:47 AM, Igor Korot wrote:
    > 
    > Reply to list also.
    > Ccing list.
    >> Adrian,
    >>
    >>
    >>
    >> On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com 
    >> <mailto:adrian.klaver@aklaver.com>> wrote:
    >>
    >>     On 3/15/26 6:23 PM, Igor Korot wrote:
    >>      > Hi, Adrian,
    >>      >
    >>      > Here is the log file from running in ODBC mode: https://bpa.st/
    >>     Z2DWG <https://bpa.st/Z2DWG>
    >>
    >>     I have no idea what this is trying to show?
    >>
    >>
    >> The log shows ODBC connection and then at the end - call to 
    >> SQLPrimaryKeys().
    > 
    > Where?
    > 
    > I don't see that in either the link you posted or the text file Greg 
    > sent to the list.
    > 
    >>
    >> If you run it against the table I posted above, you will get 3 fields. 
    >> Whereas it should be just one.
    > 
    > Again, run it how?
    
    Alright I see what you are talking about now. I'm not using the ODBC 
    driver just it's query. In psql :
    
    CREATE TABLE leagues_new (
         id serial,
         name varchar(100),
         drafttype smallint,
         scoringtype smallint,
         roundvalues smallint,
         leaguetype char(5),
         salary integer,
         benchplayers smallint,
         PRIMARY KEY (id) INCLUDE (drafttype, scoringtype
    ) WITH (fillfactor = 50, deduplicate_items = OFF)
    );
    
    
    SELECT
         ta.attname,
         ia.attnum,
         ic.relname,
         n.nspname,
         tc.relname
    FROM
         pg_catalog.pg_attribute ta,
         pg_catalog.pg_attribute ia,
         pg_catalog.pg_class tc,
         pg_catalog.pg_index i,
         pg_catalog.pg_namespace n,
         pg_catalog.pg_class ic
    WHERE
         tc.relname = 'leagues_new'
         AND n.nspname = 'public'
         AND tc.oid = i.indrelid
         AND n.oid = tc.relnamespace
         AND i.indisprimary = 't'
         AND ia.attrelid = i.indexrelid
         AND ta.attrelid = i.indrelid
         AND ta.attnum = i.indkey[ia.attnum - 1]
         AND (NOT ta.attisdropped)
         AND (NOT ia.attisdropped)
         AND ic.oid = i.indexrelid
    ORDER BY
         ia.attnum;
    
    yields
    
    attname   | attnum |     relname      | nspname |   relname
    -------------+--------+------------------+---------+-------------
      id          |      1 | leagues_new_pkey | public  | leagues_new
      drafttype   |      2 | leagues_new_pkey | public  | leagues_new
      scoringtype |      3 | leagues_new_pkey | public  | leagues_new
    
    
    > 
    >>
    >> Thank you.
    >>
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  17. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-16T21:51:22Z

    Adrian,
    
    On Mon, Mar 16, 2026 at 2:40 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/16/26 2:30 PM, Adrian Klaver wrote:
    > > On 3/16/26 11:47 AM, Igor Korot wrote:
    > >
    > > Reply to list also.
    > > Ccing list.
    > >> Adrian,
    > >>
    > >>
    > >>
    > >> On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com
    > >> <mailto:adrian.klaver@aklaver.com>> wrote:
    > >>
    > >>     On 3/15/26 6:23 PM, Igor Korot wrote:
    > >>      > Hi, Adrian,
    > >>      >
    > >>      > Here is the log file from running in ODBC mode: https://bpa.st/
    > >>     Z2DWG <https://bpa.st/Z2DWG>
    > >>
    > >>     I have no idea what this is trying to show?
    > >>
    > >>
    > >> The log shows ODBC connection and then at the end - call to
    > >> SQLPrimaryKeys().
    > >
    > > Where?
    > >
    > > I don't see that in either the link you posted or the text file Greg
    > > sent to the list.
    > >
    > >>
    > >> If you run it against the table I posted above, you will get 3 fields.
    > >> Whereas it should be just one.
    > >
    > > Again, run it how?
    >
    > Alright I see what you are talking about now. I'm not using the ODBC
    > driver just it's query. In psql :
    >
    > CREATE TABLE leagues_new (
    >      id serial,
    >      name varchar(100),
    >      drafttype smallint,
    >      scoringtype smallint,
    >      roundvalues smallint,
    >      leaguetype char(5),
    >      salary integer,
    >      benchplayers smallint,
    >      PRIMARY KEY (id) INCLUDE (drafttype, scoringtype
    > ) WITH (fillfactor = 50, deduplicate_items = OFF)
    > );
    >
    >
    > SELECT
    >      ta.attname,
    >      ia.attnum,
    >      ic.relname,
    >      n.nspname,
    >      tc.relname
    > FROM
    >      pg_catalog.pg_attribute ta,
    >      pg_catalog.pg_attribute ia,
    >      pg_catalog.pg_class tc,
    >      pg_catalog.pg_index i,
    >      pg_catalog.pg_namespace n,
    >      pg_catalog.pg_class ic
    > WHERE
    >      tc.relname = 'leagues_new'
    >      AND n.nspname = 'public'
    >      AND tc.oid = i.indrelid
    >      AND n.oid = tc.relnamespace
    >      AND i.indisprimary = 't'
    >      AND ia.attrelid = i.indexrelid
    >      AND ta.attrelid = i.indrelid
    >      AND ta.attnum = i.indkey[ia.attnum - 1]
    >      AND (NOT ta.attisdropped)
    >      AND (NOT ia.attisdropped)
    >      AND ic.oid = i.indexrelid
    > ORDER BY
    >      ia.attnum;
    >
    > yields
    >
    > attname   | attnum |     relname      | nspname |   relname
    > -------------+--------+------------------+---------+-------------
    >   id          |      1 | leagues_new_pkey | public  | leagues_new
    >   drafttype   |      2 | leagues_new_pkey | public  | leagues_new
    >   scoringtype |      3 | leagues_new_pkey | public  | leagues_new
    
    Correct.
    
    And according to the second reply it should yeld just the first record.
    
    I'm going to forward this to the ODBC list...
    
    Thank you.
    
    >
    >
    > >
    > >>
    > >> Thank you.
    > >>
    >
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  18. Fwd: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-16T21:53:49Z

    Hi, List.
    
    This is what I found out.
    
    Could someone please look into it?
    
    Thank you.
    
    
    ---------- Forwarded message ---------
    From: Igor Korot <ikorot01@gmail.com>
    Date: Mon, Mar 16, 2026 at 2:51 PM
    Subject: Re: Does included columns part of the PK
    To: Adrian Klaver <adrian.klaver@aklaver.com>
    Cc: pgsql-general <pgsql-general@postgresql.org>
    
    
    Adrian,
    
    On Mon, Mar 16, 2026 at 2:40 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/16/26 2:30 PM, Adrian Klaver wrote:
    > > On 3/16/26 11:47 AM, Igor Korot wrote:
    > >
    > > Reply to list also.
    > > Ccing list.
    > >> Adrian,
    > >>
    > >>
    > >>
    > >> On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com
    > >> <mailto:adrian.klaver@aklaver.com>> wrote:
    > >>
    > >>     On 3/15/26 6:23 PM, Igor Korot wrote:
    > >>      > Hi, Adrian,
    > >>      >
    > >>      > Here is the log file from running in ODBC mode: https://bpa.st/
    > >>     Z2DWG <https://bpa.st/Z2DWG>
    > >>
    > >>     I have no idea what this is trying to show?
    > >>
    > >>
    > >> The log shows ODBC connection and then at the end - call to
    > >> SQLPrimaryKeys().
    > >
    > > Where?
    > >
    > > I don't see that in either the link you posted or the text file Greg
    > > sent to the list.
    > >
    > >>
    > >> If you run it against the table I posted above, you will get 3 fields.
    > >> Whereas it should be just one.
    > >
    > > Again, run it how?
    >
    > Alright I see what you are talking about now. I'm not using the ODBC
    > driver just it's query. In psql :
    >
    > CREATE TABLE leagues_new (
    >      id serial,
    >      name varchar(100),
    >      drafttype smallint,
    >      scoringtype smallint,
    >      roundvalues smallint,
    >      leaguetype char(5),
    >      salary integer,
    >      benchplayers smallint,
    >      PRIMARY KEY (id) INCLUDE (drafttype, scoringtype
    > ) WITH (fillfactor = 50, deduplicate_items = OFF)
    > );
    >
    >
    > SELECT
    >      ta.attname,
    >      ia.attnum,
    >      ic.relname,
    >      n.nspname,
    >      tc.relname
    > FROM
    >      pg_catalog.pg_attribute ta,
    >      pg_catalog.pg_attribute ia,
    >      pg_catalog.pg_class tc,
    >      pg_catalog.pg_index i,
    >      pg_catalog.pg_namespace n,
    >      pg_catalog.pg_class ic
    > WHERE
    >      tc.relname = 'leagues_new'
    >      AND n.nspname = 'public'
    >      AND tc.oid = i.indrelid
    >      AND n.oid = tc.relnamespace
    >      AND i.indisprimary = 't'
    >      AND ia.attrelid = i.indexrelid
    >      AND ta.attrelid = i.indrelid
    >      AND ta.attnum = i.indkey[ia.attnum - 1]
    >      AND (NOT ta.attisdropped)
    >      AND (NOT ia.attisdropped)
    >      AND ic.oid = i.indexrelid
    > ORDER BY
    >      ia.attnum;
    >
    > yields
    >
    > attname   | attnum |     relname      | nspname |   relname
    > -------------+--------+------------------+---------+-------------
    >   id          |      1 | leagues_new_pkey | public  | leagues_new
    >   drafttype   |      2 | leagues_new_pkey | public  | leagues_new
    >   scoringtype |      3 | leagues_new_pkey | public  | leagues_new
    
    Correct.
    
    And according to the second reply it should yeld just the first record.
    
    I'm going to forward this to the ODBC list...
    
    Thank you.
    
    >
    >
    > >
    > >>
    > >> Thank you.
    > >>
    >
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  19. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-16T21:57:35Z

    On 3/16/26 2:51 PM, Igor Korot wrote:
    > Adrian,
    > 
    > On Mon, Mar 16, 2026 at 2:40 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >>
    >> On 3/16/26 2:30 PM, Adrian Klaver wrote:
    >>> On 3/16/26 11:47 AM, Igor Korot wrote:
    >>>
    >>> Reply to list also.
    >>> Ccing list.
    >>>> Adrian,
    >>>>
    >>>>
    >>>>
    >>>> On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com
    >>>> <mailto:adrian.klaver@aklaver.com>> wrote:
    >>>>
    >>>>      On 3/15/26 6:23 PM, Igor Korot wrote:
    >>>>       > Hi, Adrian,
    >>>>       >
    >>>>       > Here is the log file from running in ODBC mode: https://bpa.st/
    >>>>      Z2DWG <https://bpa.st/Z2DWG>
    >>>>
    >>>>      I have no idea what this is trying to show?
    >>>>
    >>>>
    >>>> The log shows ODBC connection and then at the end - call to
    >>>> SQLPrimaryKeys().
    >>>
    >>> Where?
    >>>
    >>> I don't see that in either the link you posted or the text file Greg
    >>> sent to the list.
    >>>
    >>>>
    >>>> If you run it against the table I posted above, you will get 3 fields.
    >>>> Whereas it should be just one.
    >>>
    >>> Again, run it how?
    >>
    >> Alright I see what you are talking about now. I'm not using the ODBC
    >> driver just it's query. In psql :
    >>
    >> CREATE TABLE leagues_new (
    >>       id serial,
    >>       name varchar(100),
    >>       drafttype smallint,
    >>       scoringtype smallint,
    >>       roundvalues smallint,
    >>       leaguetype char(5),
    >>       salary integer,
    >>       benchplayers smallint,
    >>       PRIMARY KEY (id) INCLUDE (drafttype, scoringtype
    >> ) WITH (fillfactor = 50, deduplicate_items = OFF)
    >> );
    >>
    >>
    >> SELECT
    >>       ta.attname,
    >>       ia.attnum,
    >>       ic.relname,
    >>       n.nspname,
    >>       tc.relname
    >> FROM
    >>       pg_catalog.pg_attribute ta,
    >>       pg_catalog.pg_attribute ia,
    >>       pg_catalog.pg_class tc,
    >>       pg_catalog.pg_index i,
    >>       pg_catalog.pg_namespace n,
    >>       pg_catalog.pg_class ic
    >> WHERE
    >>       tc.relname = 'leagues_new'
    >>       AND n.nspname = 'public'
    >>       AND tc.oid = i.indrelid
    >>       AND n.oid = tc.relnamespace
    >>       AND i.indisprimary = 't'
    >>       AND ia.attrelid = i.indexrelid
    >>       AND ta.attrelid = i.indrelid
    >>       AND ta.attnum = i.indkey[ia.attnum - 1]
    >>       AND (NOT ta.attisdropped)
    >>       AND (NOT ia.attisdropped)
    >>       AND ic.oid = i.indexrelid
    >> ORDER BY
    >>       ia.attnum;
    >>
    >> yields
    >>
    >> attname   | attnum |     relname      | nspname |   relname
    >> -------------+--------+------------------+---------+-------------
    >>    id          |      1 | leagues_new_pkey | public  | leagues_new
    >>    drafttype   |      2 | leagues_new_pkey | public  | leagues_new
    >>    scoringtype |      3 | leagues_new_pkey | public  | leagues_new
    > 
    > Correct.
    > 
    > And according to the second reply it should yeld just the first record.
    > 
    > I'm going to forward this to the ODBC list...
    
    I have not worked it out yet but would start with:
    
    AND ta.attnum = i.indkey[ia.attnum - 1]
    
    per
    
    www.postgresql.org/docs/current/catalog-pg-index.html
    
    "
    indkey int2vector (references pg_attribute.attnum)
    
    ...
    
    This is an array of indnatts values that indicate which table columns 
    this index indexes. For example, a value of 1 3 would mean that the 
    first and the third table columns make up the index entries. Key columns 
    come before non-key (included) columns.
    
    ...
    "
    
    Though there is the below from the same page:
    
    "indnatts int2
    
    The total number of columns in the index (duplicates pg_class.relnatts); 
    this number includes both key and included attributes
    
    indnkeyatts int2
    
    The number of key columns in the index, not counting any included 
    columns, which are merely stored and do not participate in the index 
    semantics
    "
    
    
    > 
    > Thank you.
    > 
    >>
    >>
    >>>
    >>>>
    >>>> Thank you.
    >>>>
    >>
    >>
    >> --
    >> Adrian Klaver
    >> adrian.klaver@aklaver.com
    
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  20. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-16T23:38:22Z

    Adrian,
    
    Most important - do you agree that those fields should not be in this
    recordset?
    
    Thank you.
    
    On Mon, Mar 16, 2026 at 2:57 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/16/26 2:51 PM, Igor Korot wrote:
    > > Adrian,
    > >
    > > On Mon, Mar 16, 2026 at 2:40 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    > >>
    > >> On 3/16/26 2:30 PM, Adrian Klaver wrote:
    > >>> On 3/16/26 11:47 AM, Igor Korot wrote:
    > >>>
    > >>> Reply to list also.
    > >>> Ccing list.
    > >>>> Adrian,
    > >>>>
    > >>>>
    > >>>>
    > >>>> On Mon, Mar 16, 2026, 8:03 AM Adrian Klaver <adrian.klaver@aklaver.com
    > >>>> <mailto:adrian.klaver@aklaver.com>> wrote:
    > >>>>
    > >>>>      On 3/15/26 6:23 PM, Igor Korot wrote:
    > >>>>       > Hi, Adrian,
    > >>>>       >
    > >>>>       > Here is the log file from running in ODBC mode: https://bpa.st/
    > >>>>      Z2DWG <https://bpa.st/Z2DWG>
    > >>>>
    > >>>>      I have no idea what this is trying to show?
    > >>>>
    > >>>>
    > >>>> The log shows ODBC connection and then at the end - call to
    > >>>> SQLPrimaryKeys().
    > >>>
    > >>> Where?
    > >>>
    > >>> I don't see that in either the link you posted or the text file Greg
    > >>> sent to the list.
    > >>>
    > >>>>
    > >>>> If you run it against the table I posted above, you will get 3 fields.
    > >>>> Whereas it should be just one.
    > >>>
    > >>> Again, run it how?
    > >>
    > >> Alright I see what you are talking about now. I'm not using the ODBC
    > >> driver just it's query. In psql :
    > >>
    > >> CREATE TABLE leagues_new (
    > >>       id serial,
    > >>       name varchar(100),
    > >>       drafttype smallint,
    > >>       scoringtype smallint,
    > >>       roundvalues smallint,
    > >>       leaguetype char(5),
    > >>       salary integer,
    > >>       benchplayers smallint,
    > >>       PRIMARY KEY (id) INCLUDE (drafttype, scoringtype
    > >> ) WITH (fillfactor = 50, deduplicate_items = OFF)
    > >> );
    > >>
    > >>
    > >> SELECT
    > >>       ta.attname,
    > >>       ia.attnum,
    > >>       ic.relname,
    > >>       n.nspname,
    > >>       tc.relname
    > >> FROM
    > >>       pg_catalog.pg_attribute ta,
    > >>       pg_catalog.pg_attribute ia,
    > >>       pg_catalog.pg_class tc,
    > >>       pg_catalog.pg_index i,
    > >>       pg_catalog.pg_namespace n,
    > >>       pg_catalog.pg_class ic
    > >> WHERE
    > >>       tc.relname = 'leagues_new'
    > >>       AND n.nspname = 'public'
    > >>       AND tc.oid = i.indrelid
    > >>       AND n.oid = tc.relnamespace
    > >>       AND i.indisprimary = 't'
    > >>       AND ia.attrelid = i.indexrelid
    > >>       AND ta.attrelid = i.indrelid
    > >>       AND ta.attnum = i.indkey[ia.attnum - 1]
    > >>       AND (NOT ta.attisdropped)
    > >>       AND (NOT ia.attisdropped)
    > >>       AND ic.oid = i.indexrelid
    > >> ORDER BY
    > >>       ia.attnum;
    > >>
    > >> yields
    > >>
    > >> attname   | attnum |     relname      | nspname |   relname
    > >> -------------+--------+------------------+---------+-------------
    > >>    id          |      1 | leagues_new_pkey | public  | leagues_new
    > >>    drafttype   |      2 | leagues_new_pkey | public  | leagues_new
    > >>    scoringtype |      3 | leagues_new_pkey | public  | leagues_new
    > >
    > > Correct.
    > >
    > > And according to the second reply it should yeld just the first record.
    > >
    > > I'm going to forward this to the ODBC list...
    >
    > I have not worked it out yet but would start with:
    >
    > AND ta.attnum = i.indkey[ia.attnum - 1]
    >
    > per
    >
    > www.postgresql.org/docs/current/catalog-pg-index.html
    >
    > "
    > indkey int2vector (references pg_attribute.attnum)
    >
    > ...
    >
    > This is an array of indnatts values that indicate which table columns
    > this index indexes. For example, a value of 1 3 would mean that the
    > first and the third table columns make up the index entries. Key columns
    > come before non-key (included) columns.
    >
    > ...
    > "
    >
    > Though there is the below from the same page:
    >
    > "indnatts int2
    >
    > The total number of columns in the index (duplicates pg_class.relnatts);
    > this number includes both key and included attributes
    >
    > indnkeyatts int2
    >
    > The number of key columns in the index, not counting any included
    > columns, which are merely stored and do not participate in the index
    > semantics
    > "
    >
    >
    > >
    > > Thank you.
    > >
    > >>
    > >>
    > >>>
    > >>>>
    > >>>> Thank you.
    > >>>>
    > >>
    > >>
    > >> --
    > >> Adrian Klaver
    > >> adrian.klaver@aklaver.com
    >
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  21. Re: Does included columns part of the PK

    Adrian Klaver <adrian.klaver@aklaver.com> — 2026-03-17T00:44:45Z

    On 3/16/26 4:38 PM, Igor Korot wrote:
    > Adrian,
    > 
    > Most important - do you agree that those fields should not be in this
    > recordset?
    
    I don't see anything here:
    
    https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlprimarykeys-function?view=sql-server-ver17
    
    that says they should be returned. Though the above also says:
    
    " Additional columns beyond column 6 (PK_NAME) can be defined by the 
    driver."
    
    That is not the case here, where additional rows are used. However it 
    does allow for more information to be supplied.
    
    My purely un-expert analysis is, no the extra rows should not be there.
    
    > 
    > Thank you.
    
    -- 
    Adrian Klaver
    adrian.klaver@aklaver.com
    
    
    
    
  22. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-03-17T01:11:26Z

    Adrian,,
    
    On Mon, Mar 16, 2026 at 5:44 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    >
    > On 3/16/26 4:38 PM, Igor Korot wrote:
    > > Adrian,
    > >
    > > Most important - do you agree that those fields should not be in this
    > > recordset?
    >
    > I don't see anything here:
    >
    > https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlprimarykeys-function?view=sql-server-ver17
    >
    > that says they should be returned. Though the above also says:
    >
    > " Additional columns beyond column 6 (PK_NAME) can be defined by the
    > driver."
    >
    > That is not the case here, where additional rows are used. However it
    > does allow for more information to be supplied.
    >
    > My purely un-expert analysis is, no the extra rows should not be there.
    
    Thx for confirming.
    
    I already forwarded the email with the query results over to ODBC list.
    
    Hopefully someone can come back soon.
    
    Are you reading that list as well? If not I will update this thread
    with the results.
    
    Thank you.
    
    >
    > >
    > > Thank you.
    >
    > --
    > Adrian Klaver
    > adrian.klaver@aklaver.com
    
    
    
    
  23. Re: Does included columns part of the PK

    Igor Korot <ikorot01@gmail.com> — 2026-04-21T05:33:33Z

    For all involved and interested:
    
    The issue with ODBC driver has been fixed and will
    be part of the next release.
    
    Ref: https://github.com/postgresql-interfaces/psqlodbc/issues/170.
    
    Thank you.
    
    On Mon, Mar 16, 2026 at 6:11 PM Igor Korot <ikorot01@gmail.com> wrote:
    >
    > Adrian,,
    >
    > On Mon, Mar 16, 2026 at 5:44 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
    > >
    > > On 3/16/26 4:38 PM, Igor Korot wrote:
    > > > Adrian,
    > > >
    > > > Most important - do you agree that those fields should not be in this
    > > > recordset?
    > >
    > > I don't see anything here:
    > >
    > > https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlprimarykeys-function?view=sql-server-ver17
    > >
    > > that says they should be returned. Though the above also says:
    > >
    > > " Additional columns beyond column 6 (PK_NAME) can be defined by the
    > > driver."
    > >
    > > That is not the case here, where additional rows are used. However it
    > > does allow for more information to be supplied.
    > >
    > > My purely un-expert analysis is, no the extra rows should not be there.
    >
    > Thx for confirming.
    >
    > I already forwarded the email with the query results over to ODBC list.
    >
    > Hopefully someone can come back soon.
    >
    > Are you reading that list as well? If not I will update this thread
    > with the results.
    >
    > Thank you.
    >
    > >
    > > >
    > > > Thank you.
    > >
    > > --
    > > Adrian Klaver
    > > adrian.klaver@aklaver.com