Add mixed affinity UPDATE, unify UUID behaviour

[mkgrgis]

In this PR

• UPDATE works with column_type option for mixed affinity cases and writes different affinity values depends on value of the option. This fix Column option column_type doesn't works with UPDATE #90. This issue affects uuid and timestamp types of data, implemented in different time. Mixed affinity timestamp was implemented before uuid support in Add uuid support #82,
• UUID behaviour and tests are unified between all supported PostgreSQL versions for full mixed affinity support with both of SELECT/WHERE usage, INSERT and UPDATE,
• regress tests reordered: sqlite_fdw_post firsts, than tests about data types in ABC order, other sequence with no changes,
• add a function which converted column_type option value to SQLite affinity code for standard values with int as integer affinity synonym,
• uuid test renumbering and add COSTS OFF in some TCs,
• add to uuid test important TC about semantics conflict in SQLite: the same UUID values with different affinity, but no error during SQLite unique check,
• add current behaviour for Infinity values in floatN column into type tests with SQLite unique value check. No code changes. This behaviour should be tested before special planned PR about special values in floatN columns,
• add translation rule for IMPORT FOREIGN SCHEMA if SQLite formal column name is uuid.

[mkgrgis]

@t-kataym , could you please write me approximate date of review of this PR?

[t-kataym]

@mkgrgis , Thank you for your contribution. We would like to confirm the PR and then merge it in this month if no problem.

[mkgrgis]

Thanks, @t-kataym ! In this case I'll also prepare PR with macaddr and macaddr8 support to the end of April.

[son-phamngoc]

Hello @mkgrgis , thanks for your hard work.
I have 2 questions about this description. Could you help me to answer them?

add translation rule for IMPORT FOREIGN SCHEMA if SQLite formal column name is uuid.

I see that you created a custom function to convert text/blob to uuid, and deparsed remote UPDATE query to call it. Therefore, I think this change should be for UPDATE, not IMPORT FOREIGN SCHEMA. Is that correct?

special_affinity = (pg_attyp == UUIDOID && preferred_affinity == SQLITE3_TEXT) ||
                   (pg_attyp == TIMESTAMPOID && preferred_affinity == SQLITE_INTEGER);
if (special_affinity)
{
    ....

I see that you handled 2 cases here: uuid and timestamp, but your description in this PR only mentioned about uuid case.
Could you add more description for timestamp case?

[mkgrgis]

Thanks, @son-phamngoc ! Added in description

fix #90. This issue affects uuid and timestamp types of data, implemented in different time. Mixed affinity timestamp was implemented before uuid support in #82,

The second

I see that you created a custom function to convert text/blob to uuid, and deparsed remote UPDATE query to call it. Therefore, I think this change should be for UPDATE, not IMPORT FOREIGN SCHEMA. Is that correct?

Yes. Rule for IMPORT FOREIGN SCHEMA is outside of deparsing. It's only about better table auto DDL for PostgreSQL. In SQLite was no strict column data types or affinity before special CREATE TABLE ...STRICT mode.

[son-phamngoc]

Yes. Rule for IMPORT FOREIGN SCHEMA is outside of deparsing. It's only about better table auto DDL for PostgreSQL. In SQLite was no strict column data types or affinity before special CREATE TABLE ...STRICT mode.

@mkgrgis So, I think the description should be "add translation rule for UPDATE if SQLite formal column name is uuid.". Could you update it?

[mkgrgis]

So, I think the description should be "add translation rule for UPDATE if SQLite formal column name is uuid

No, @son-phamngoc. In SQLite data processing code there is a common good style not to use formal column definitions at all, only affinity de facto of a SQLite data value. UPDATE, SELECT, any WHERE etc. works only based on affinity.
In this FDW common code style is not applicable only to a function for IMPORT FOREIGN SCHEMA. In my PR there is no formal column definition usage outside of the function. Why? Because IMPORT FOREIGN SCHEMA gives recommended data types for PostgreSQL based on SQLite formal column definitions. FDW thinks the result will be normal, but is ready to any affinity according https://github.com/pgspider/sqlite_fdw/tree/master?tab=readme-ov-file#datatypes .

[son-phamngoc]

@mkgrgis I thought that description related to your modification in sqlite_deparse_direct_update_sql function of deparse.c.
But according to your explanation, it seems it is different.
Could you point me out which parts of your modification related to that description? I do not see any code change or test case related to IMPORT FOREIGN SCHEMA in this PR.

[mkgrgis]

Could you point me out which parts of your modification related to that description?

I am sorry, @son-phamngoc. There was no that modification. I was sure this was committed by me, but before 9c81b0f this was only in my private draft. Now this is fixed.

[son-phamngoc]

@mkgrgis Thanks for your support.
I reviewed you PR. Could you check my comments?

[mkgrgis]

I reviewed you PR. Could you check my comments?

All your comments are checked, @son-phamngoc ! Let's request the second review?

[son-phamngoc]

@mkgrgis Thanks for your support.
I executed test for this PR in my environment and they all passed.
I see no problem in this PR for now.
I will leave the decision to @t-kataym.

[t-kataym]

@son-phamngoc Thank you for your confirmation.
@mkgrgis Thank you for your contribution.
I will merge the PR.

[mkgrgis]

Thanks, @t-kataym! My next PR from #66 series will be about ∞ in float and numeric data, the branch is almost ready.

[mkgrgis]

Mixed affinity support PRs continued with #97.