Re: force_not_null option support for file_fdw

Hi Hanada-san.

> ISTM that your results are reasonable for each collation setting.
> Former ordering is same as C locale, and in latter case alphabetical order has priority over case
> distinctions.  Do you mean that ordering used in file_fdw is affected from something unexpected, without
> collation or locale setting?
>
> BTW, I found a thread which is related to this issue.
>   http://archives.postgresql.org/pgsql-hackers/2011-09/msg00130.php
>
> I changed the test data so that it uses only upper case alphabets, because case distinction is not
> important for that test.  I also removed digits to avoid test failure in some locales which sort
> alphabets before digits.
>
OK, Thanks for this clarification. This change of regression test case seems to me reasonable
to avoid unnecessary false-positive.

I found one other point to be fixed:
On get_force_not_null(), it makes a list of attribute names with force_not_null option.

+       foreach (cell, options)
+       {
+           DefElem    *def = (DefElem *) lfirst(cell);
+           const char *value = defGetString(def);
+
+           if (strcmp(def->defname, "force_not_null") == 0 &&
+               strcmp(value, "true") == 0)
+           {
+               columns = lappend(columns, makeString(NameStr(attr->attname)));
+               elog(DEBUG1, "%s: force_not_null", NameStr(attr->attname));
+           }
+
+       }

makeString() does not copy the supplied string itself, so it is not preferable to reference
NameStr(attr->attname) across ReleaseSysCache().
I'd like to suggest to supply a copied attname using pstrdup for makeString

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@emea.nec.com>


> -----Original Message-----
> From: Shigeru Hanada [mailto:shigeru.hanada@gmail.com]
> Sent: 8. September 2011 06:19
> To: Kohei Kaigai
> Cc: Kohei KaiGai; PostgreSQL-development
> Subject: Re: [HACKERS] force_not_null option support for file_fdw
>
> (2011/09/05 22:05), Kohei Kaigai wrote:
> >> In my usual environment that test passed, but finally I've reproduced
> >> the failure with setting $LC_COLLATE to "es_ES.UTF-8".  Do you have set any $LC_COLLATE in your
> test environment?
> >>
> > It is not set in my environment.
> >
> > I checked the behavior of ORDER BY when we set a collation on the regular relation, not a foreign
> table.
> > Do we hit something other unexpected bug in collation here?
> >
> > postgres=# CREATE TABLE t1 (word1 text); CREATE TABLE postgres=#
> > INSERT INTO t1 VALUES ('ABC'),('abc'),('123'),('NULL'); INSERT 0 4
> > postgres=# ALTER TABLE t1 ALTER word1 TYPE text COLLATE "ja_JP.utf8";
> > ALTER TABLE postgres=# SELECT * FROM t1 ORDER BY word1;
> >   word1
> > -------
> >   123
> >   ABC
> >   NULL
> >   abc
> > (4 rows)
> >
> > postgres=# ALTER TABLE t1 ALTER word1 TYPE text COLLATE "en_US.utf8";
> > ALTER TABLE postgres=# SELECT * FROM t1 ORDER BY word1;
> >   word1
> > -------
> >   123
> >   abc
> >   ABC
> >   NULL
> > (4 rows)
>
> Thanks for the checking.  FYI, I mainly use Fedora 15 box with Japanese environment for my development.
>
> ISTM that your results are reasonable for each collation setting.
> Former ordering is same as C locale, and in latter case alphabetical order has priority over case
> distinctions.  Do you mean that ordering used in file_fdw is affected from something unexpected, without
> collation or locale setting?
>
> BTW, I found a thread which is related to this issue.
>   http://archives.postgresql.org/pgsql-hackers/2011-09/msg00130.php
>
> I changed the test data so that it uses only upper case alphabets, because case distinction is not
> important for that test.  I also removed digits to avoid test failure in some locales which sort
> alphabets before digits.
>
> Regards,
> --
> Shigeru Hanada
>
>
>  Click
> https://www.mailcontrol.com/sr/fB6Wmr8zmMzTndxI!oX7Uo9cpkuWnNqkEgc!P6cHvBhGb4EkL1te5Ky38yYzoE4Mra
> 3ljAyIpUlPbv5+FCDqIw==  to report this email as spam.