> 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,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kai...@emea.nec.com>
> -----Original Message-----
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
