Skip site navigation (1) Skip section navigation (2)

Re: force_not_null option support for file_fdw

From: Kohei Kaigai <Kohei(dot)Kaigai(at)EMEA(dot)NEC(dot)COM>
To: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Kohei KaiGai<kaigai(at)kaigai(dot)gr(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: force_not_null option support for file_fdw
Date: 2011-09-05 13:05:06
Message-ID: D0C1A1F8BF513F469926E6C71461D9EC0540CD@EX10MBX02.EU.NEC.COM (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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(dot)kaigai(at)emea(dot)nec(dot)com>


> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-owner(at)postgresql(dot)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.

In response to

Responses

pgsql-hackers by date

Next:From: Yeb HavingaDate: 2011-09-05 13:14:37
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Previous:From: Heikki LinnakangasDate: 2011-09-05 11:10:54
Subject: Re: WIP: Fast GiST index build

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group