Re: force_not_null option support for file_fdw

> 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
-------123ABCNULLabc
(4 rows)

postgres=# ALTER TABLE t1 ALTER word1 TYPE text COLLATE "en_US.utf8";
ALTER TABLE
postgres=# SELECT * FROM t1 ORDER BY word1;word1
-------123abcABCNULL
(4 rows)

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


> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
> Shigeru Hanada
> Sent: 5. September 2011 06:56
> To: Kohei KaiGai
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] force_not_null option support for file_fdw
>
> Thanks for the review.
>
> (2011/09/05 3:55), Kohei KaiGai wrote:
> > I tried to review this patch.
> >
> > It seems to me its implementation is reasonable and enough simple.
> > All the works of this patch is pick-up "force_not_null" option from
> > pg_attribute.attfdwoptions and transform its data structure into
> > suitable form to the existing BeginCopyFrom().
> > So, I'd almost like to mark this patch "Ready for Committer".
> >
> > Here are only two points I'd like to comment on.
> >
> > +       tuple = SearchSysCache2(ATTNUM,
> > +                               RelationGetRelid(rel),
> > +                               Int16GetDatum(attnum));
> > +       if (!HeapTupleIsValid(tuple))
> > +           ereport(ERROR,
> > +                   (errcode(ERRCODE_UNDEFINED_OBJECT),
> > +                    errmsg("cache lookup failed for attribute %d of
> > relation %u",
> > +                           attnum, RelationGetRelid(rel))));
> >
> > The tuple should be always found unless we have any bugs that makes
> > mismatch between pg_class.relnatts and actual number of attributes.
> > So, it is a case to use elog(), instead of ereport() with error code.
>
> Oh, I've missed that other similar errors use elog()...
> Fixed.
>
> > One other point is diffset of regression test, when I run `make check
> > -C contrib/file_fdw'.
> > Do we have something changed corresponding to COPY TO/FROM statement
> > since 8th-August to now?
>
> I don't know about such change, and src/backend/command/copy.c has not been touched since Feb 23.
>
> > *** /home/kaigai/repo/sepgsql/contrib/file_fdw/expected/file_fdw.out
> >   2011-09-04 20:36:23.670981921 +0200
> > --- /home/kaigai/repo/sepgsql/contrib/file_fdw/results/file_fdw.out
> >   2011-09-04 20:36:51.202989681 +0200
> > ***************
> > *** 118,126 ****
> >     word1 | word2
> >    -------+-------
> >     123   | 123
> >     ABC   | ABC
> >     NULL  |
> > -  abc   | abc
> >    (4 rows)
> >
> >    -- basic query tests
> > --- 118,126 ----
> >     word1 | word2
> >    -------+-------
> >     123   | 123
> > +  abc   | abc
> >     ABC   | ABC
> >     NULL  |
> >    (4 rows)
> >
> >    -- basic query tests
> >
> > ======================================================================
>
> 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?
>
> Regards,
> --
> Shigeru Hanada
>
>
>
>  Click
> https://www.mailcontrol.com/sr/yQEP2keV9uzTndxI!oX7UgZzT7dlvrTeW0pvcI7!FpP+qgioCQTZMxIe1v95Rjzlbr
> CRFdjEt0BTEf5tQBqpNg==  to report this email as spam.