Re: [HACKERS] locale problem of bgworker: logical replication launcher and worker process

[Ioseph Kim]

Thanks for reply.

I resolved this problem.

This problem is that dgettext() function use codeset of database's lc_ctype.

below database's lc_ctype is C, but locale is ko_KR.UTF8.

I made a new database with lc_ctype is ko_KR.UTF8.

this problem is resolved.



work logs are here.


(10) postgres@postgres=# \l
   데이터베이스 목록
   이름|  소유주  | 인코딩 | Collate |Ctype|  액세스 권한
---+--++-+-+---
 krdb  | postgres | UTF8   | C   | ko_KR.UTF-8 |
 postgres  | postgres | UTF8   | C   | C   |
 template0 | postgres | UTF8   | C   | C   | 
=c/postgres  +
   |  || | | 
postgres=CTc/postgres
 template1 | postgres | UTF8   | C   | C   | 
=c/postgres  +
   |  || | | 
postgres=CTc/postgres

(4개 행)

(10) postgres@postgres=# \c
접속정보: 데이터베이스="postgres", 사용자="postgres".
(10) postgres@postgres=# create subscription sub1 connection 
'host=127.0.0.1 port=5432 client_encoding=C' publication pub1;
2017-08-25 18:13:34.556 KST [5401] 오류:  발행 서버에 연결 할 수 없음: ??? 
??? ? ??: ??? ???

"127.0.0.1"  ??? ?? ???,
5432 ??? TCP/IP ???  ??.
2017-08-25 18:13:34.556 KST [5401] 명령 구문:  create subscription sub1 
connection 'host=127.0.0.1 port=5432 client_encoding=C' publication pub1;

오류:  발행 서버에 연결 할 수 없음: ??? ??? ? ??: ??? ???
"127.0.0.1"  ??? ?? ???,
5432 ??? TCP/IP ???  ??.
(10) postgres@postgres=# \c krdb
접속정보: 데이터베이스="krdb", 사용자="postgres".
(10) postgres@krdb=# create subscription sub1 connection 'host=127.0.0.1 
port=5432 client_encoding=C' publication pub1;
2017-08-25 18:13:45.687 KST [5402] 오류:  발행 서버에 연결 할 수 없음: 
서버에 연결할 수 없음: 연결이 거부됨

"127.0.0.1" 호스트에 서버가 가동 중인지,
5432 포트로 TCP/IP 연결이 가능한지 살펴보십시오.
2017-08-25 18:13:45.687 KST [5402] 명령 구문:  create subscription sub1 
connection 'host=127.0.0.1 port=5432 client_encoding=C' publication pub1;

오류:  발행 서버에 연결 할 수 없음: 서버에 연결할 수 없음: 연결이 거부됨
"127.0.0.1" 호스트에 서버가 가동 중인지,
5432 포트로 TCP/IP 연결이 가능한지 살펴보십시오.


2017년 08월 23일 22:40에 Peter Eisentraut 이(가) 쓴 글:

On 8/22/17 01:19, Ioseph Kim wrote:

2017-08-22 14:06:21.697 KST [306] 로그:  logical replication apply
worker for subscription "replica_a" has started
2017-08-22 14:06:21.698 KST [306] 오류:  발행 서버에 연결 할 수 없음:
??? ??? ? ??: ??? ???
 "localhost" (::1)  ??? ?? ???,
 5432 ??? TCP/IP ???  ??.
 ??? ??? ? ??: ??? ???
 "localhost" (127.0.0.1)  ??? ?? ???,
 5432 ??? TCP/IP ???  ??.
-

main postmaster messages are printed  in korean well,
but bgworker process message is not.

This problem seems to have occurred because the server locale
environment and the client's that are different.

I have tried it locally with a ko_KR locale, and it seems to work
correctly for me.  Still, I can imagine there are all kinds of ways this
could go wrong in particular configurations.  Could you construct a
reproducible test setup, including specific initdb and locale settings,
operating system, etc.?





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] locale problem of bgworker: logical replication launcher and worker process

[Ioseph Kim]

Hi,
I tried ver. 10 beta3.
I had below messages.

-
$ pg_ctl start
서버를 시작하기 위해 기다리는 중완료
서버 시작됨
2017-08-22 14:06:21.248 KST [32765] 로그:  IPv6, 주소: "::1", 포트 5433 
번으로 접속을 허용합니다
2017-08-22 14:06:21.248 KST [32765] 로그:  IPv4, 주소: "127.0.0.1", 포트 
5433 번으로 접속을 허용합니다
2017-08-22 14:06:21.364 KST [32765] 로그:  "/tmp/.s.PGSQL.5433" 유닉스 
도메인 소켓으로 접속을 허용합니다
2017-08-22 14:06:21.570 KST [32766] 로그:  데이터베이스 시스템 마지막 가동 
중지 시각: 2017-08-22 14:04:52 KST
2017-08-22 14:06:21.570 KST [32766] 로그:  recovered replication state of 
node 1 to 0/0
2017-08-22 14:06:21.638 KST [32765] 로그:  이제 데이터베이스 서버로 접속할 
수 있습니다
2017-08-22 14:06:21.697 KST [306] 로그:  logical replication apply worker 
for subscription "replica_a" has started
2017-08-22 14:06:21.698 KST [306] 오류:  발행 서버에 연결 할 수 없음: ??? 
??? ? ??: ??? ???

"localhost" (::1)  ??? ?? ???,
5432 ??? TCP/IP ???  ??.
??? ??? ? ??: ??? ???
"localhost" (127.0.0.1)  ??? ?? ???,
5432 ??? TCP/IP ???  ??.
-

main postmaster messages are printed  in korean well,
but bgworker process message is not.

This problem seems to have occurred because the server locale 
environment and the client's that are different.


How I can resolv that?

Regards ioseph.

[HACKERS] Proposal: add error message in backend/catalog/index.c

[Ioseph Kim]

Hi,

I propose to append an error message when index name and table name are 
same.



example:

postgres@postgres=# create table t (a int not null, constraint t primary 
key (a));

ERROR:  relation "t" already exists


End users will  confusing pretty, because if users meet this message, 
users will check pg_class,


but they will not found in pg_class.

in this case,

"index name must not be same relation name" error message is better.


Some RDBMS are allow that table name and constraint unique, primary key 
name are same.


if they meet that message(relation "t" already exists), that message is 
not clear.



Regards, Ioseph

Re: [HACKERS] increase message string buffer size of watch command of psql

[Ioseph Kim]

Thanks, I agree that strftime() is better then asctime().

regards, Ioseph

2016년 06월 16일 08:37에 Tom Lane 이(가) 쓴 글:
> Alvaro Herrera  writes:
>> +1 to strftime("%c").  If we wanted to provide additional flexibility we
>> could have a \pset option to change the strftime format string to
>> something other than %c, but I don't think there's enough demand to
>> justify it.
> Agreed, that seems like something for later (or never).  Pushed that way.
>
> I also widened the buffer a bit in the back branches, to address the
> original complaint.
>
>   regards, tom lane



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] increase message string buffer size of watch command of psql

[Ioseph Kim]

2016년 06월 15일 01:56에 Tom Lane 이(가) 쓴 글:
I take it from the vast silence that nobody particularly cares one way 
or the other. On reflection I think that this would be a good change 
to make, so I'll go do so unless I hear complaints soon. regards, tom 
lane 


I propose to change from asctime() to sql current_timestamp value,
then users will  change date format with set command DateStyle.

Regards, Ioseph.



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] increase message string buffer size of watch command of psql

[Ioseph Kim]

Hello.
In po.ko (korean message) at psql 
#: command.c:2971
#, c-format
msgid "Watch every %lds\t%s"
msgstr "%ld초 간격으로 지켜보기\t%s"

this message string is a cut string, because buffer size is small.
At line 2946 in src/bin/psql/command.c 
chartitle[50];

size of message string for korean is over 50 bytes.
(at least 80 columns terminal for common)

Increase size of this title, please.
50 bytes is so small for multi language.

And. I suggest that date string might be local language,
or current_timestamp string.

Regards, Ioseph.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] propose: detail binding error log

[Ioseph Kim]

thanks for reply.

Craig wrote:
>> At the time PostgreSQL parses the statement it doesn't know the 
>> parameter values yet, because PgJDBC hasn't sent them to it. It  
>> cannot log them even if they mattered, which they don't.

I know already that, so I wrote how can see error value at server log.


case 1: in psql simple query

ERROR:  42804: column "a" is of type integer but expression is of type
text at character 45
HINT:  You will need to rewrite or cast the expression.
LOCATION:  transformAssignedExpr, parse_target.c:529
STATEMENT:  prepare aaa (text) as insert into b values ($1);

when this case, server error log is right that does not know value
because not yet be assigned.

but.
case 2: in jdbc program.
ERROR:  42804: column "a" is of type boolean but expression is of type
integer at character 25
HINT:  You will need to rewrite or cast the expression.
LOCATION:  transformAssignedExpr, parse_target.c:529
STATEMENT:  insert into test values ($1)

when this case, statement is 'insert', I think binding values already
sent to server, then server can display these.

I want see that
"ERROR:  42804: column "a" is of type boolean but expression is of type
integer(input value = 24) at character 25"

Best regards, Ioseph.


2016-03-15 (화), 13:54 +0800, Craig Ringer:
> On 15 March 2016 at 10:52, Ioseph Kim <pgsql...@postgresql.kr> wrote:
> Hi, hackers.
> 
> I had a error message while using PostgreSQL.
> 
> "ERROR:  42804: column "a" is of type boolean but expression
> is of type
> integer at character 25
> LOCATION:  transformAssignedExpr, parse_target.c:529"
> 
> This error is a java jdbc binding error.
> column type is boolean but bind variable is integer.
> 
> I want see that value of bind variable at a server log.
> 
> 
> log_statement = 'all' will log bind var values, but only when the
> statement actually gets executed.
> 
> 
> This is an error in parsing or parameter binding, before we execute
> the statement. It's a type error and not related to the actual value
> of the bind variable - you could put anything in the variable and you
> would get the same error.
> 
> 
> PostgreSQL is complaining that you bound an integer variable and tried
> to insert it into a boolean column. There is no implicit cast from
> integer to boolean, so that's an error. It doesn't care if the integer
> is 1, 42, or null, since this is a type error. There's no need to log
> the value since it's irrelevant.
> 
> 
> Observe:
> 
> 
> postgres=# create table demo(col boolean);
> CREATE TABLE
> 
> 
> postgres=# prepare my_insert(boolean) AS insert into demo(col) values
> ($1);
> PREPARE
> 
> 
> postgres=# prepare my_insertint(integer) AS insert into demo(col)
> values ($1);
> ERROR:  column "col" is of type boolean but expression is of type
> integer
> LINE 1: ... my_insertint(integer) AS insert into demo(col) values
> ($1);
>^
> HINT:  You will need to rewrite or cast the expression.
> 
> 
> 
> 
> As you see, the error is at PREPARE time, when we parse and validate
> the statement, before we bind parameters to it. You can get the same
> effect without prepared statements by specifying the type of a literal
> explicitly:
> 
> 
> postgres=# insert into demo(col) values ('1'::integer);
> ERROR:  column "col" is of type boolean but expression is of type
> integer
> LINE 1: insert into demo(col) values ('1'::integer);
>   ^
> HINT:  You will need to rewrite or cast the expression.
> 
> 
> 
> 
> At the time PostgreSQL parses the statement it doesn't know the
> parameter values yet, because PgJDBC hasn't sent them to it. It
>  cannot log them even if they mattered, which they don't.
> 
> 
> -- 
>  Craig Ringer   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
> 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] propose: detail binding error log

[Ioseph Kim]

thanks for reply.

value of log_statement is already 'all'
I set log_min_messages = debug5, log_error_verbosity = verbose and
debug_print_parse = on too.
but I could not a value of client in server log.

this case is occured only at jdbc prepare statement and wrong type
binding.

reguards, Ioseph.

 
2016-03-14 (월), 23:06 -0400, Tom Lane:
> Ioseph Kim <pgsql...@postgresql.kr> writes:
> > I want see that value of bind variable at a server log.
> 
> That's available if you turn on log_statements, IIRC.
> 
>   regards, tom lane
> 
> 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] propose: detail binding error log

[Ioseph Kim]

Hi, hackers.

I had a error message while using PostgreSQL.

"ERROR:  42804: column "a" is of type boolean but expression is of type
integer at character 25
LOCATION:  transformAssignedExpr, parse_target.c:529"

This error is a java jdbc binding error.
column type is boolean but bind variable is integer.

I want see that value of bind variable at a server log.

java code:
pstmt = connection.prepareStatement("insert into test values (?)");
pstmt.setInt(1, 1);

I could not see that value at a server log, by changing any servier
configurations.

That case is debuged to client only.

So, I propose that error value of bind variable will be displayed at a
server log.
 
in parse_target.c:529,
input parameter value of that node not containded value of column at
client.

I want more detail error log.

Regards, Ioseph Kim



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

[Ioseph Kim]

Thanks.

Korean Document is translating currently.
When that be done, I will announce to official site.
current, translation progress is 50%.
This work is dependent only voluntary support by 6 peoples.
so, translating is very slow. :)

I also hope that many Korean documents appear on the official site.

Regards, Ioseph

2016-03-07 (월), 11:19 +0900, Tatsuo Ishii:
> You'd better to ask to place the below above to
> http://www.postgresql.org/docs/.  Currently only French and Japanese
> are listed. I'm sure there are more local translations.
> 
> Not only people living in Korea are interested in Korean translated
> docs. There are many Korean speaking people in the world. Same thing
> can be said to other languages of course.
> 
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> 
> > Thanks too!
> > 
> > Korean User Group has been translating PGDoc since 2013.
> > 
> > I'll append Copyright in PGDoc.kr too. 
> > http://postgresql.kr/docs/current/
> > 
> > Regards, Ioseph.
> > 
> > 
> > 2016-03-04 (금), 17:55 -0800, Joshua D. Drake:
> >> On 03/04/2016 05:39 PM, Tatsuo Ishii wrote:
> >> > JPUG (Japan PostgreSQL Users Group) would like to add a copyright
> >> > ntice to the Japanese translated docs.
> >> >
> >> > http://www.postgresql.jp/document/9.5/html/
> >> >
> >> > Currently "Copyright 1996-2016 The PostgreSQL Global Development
> >> > Group" is showed on the translated doc (of course in Japanese). What
> >> > JPUG is wanting is, adding something like "Copyright 2016 Japan
> >> > PostgreSQL Users Group" to this.
> >> 
> >> As I understand it the translation would be copyrighted by the people 
> >> that do the translation so it is perfectly reasonable to have JPUG hold 
> >> the copyright for the .jp translation.
> >> 
> >> >
> >> > The reason for this is, "Copyright 1996-2016 The PostgreSQL Global
> >> > Development Group" may not be effective from the point of Japan laws
> >> > because "The PostgreSQL Global Development Group" is not a valid
> >> > entity to be copyright holder according to Japan's laws. To prevent
> >> > from abuses of the translated docs, JPUG thinks that JPUG needs to add
> >> > the copyright notice by JPUG to the Japanese translated docs (note
> >> > that JPUG is a registered non profit organization and can be a
> >> > copyright holder).
> >> 
> >> Considering they are BSD licensed, I am not sure what abuses could be 
> >> taken?
> >> 
> >> Sincerely,
> >> 
> >> JD
> >> 
> >> -- 
> >> Command Prompt, Inc.  http://the.postgres.company/
> >>  +1-503-667-4564
> >> PostgreSQL Centered full stack support, consulting and development.
> >> Everyone appreciates your honesty, until you are honest with them.
> >> 
> >> 
> > 
> > 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

[Ioseph Kim]

Thanks too!

Korean User Group has been translating PGDoc since 2013.

I'll append Copyright in PGDoc.kr too. 
http://postgresql.kr/docs/current/

Regards, Ioseph.


2016-03-04 (금), 17:55 -0800, Joshua D. Drake:
> On 03/04/2016 05:39 PM, Tatsuo Ishii wrote:
> > JPUG (Japan PostgreSQL Users Group) would like to add a copyright
> > ntice to the Japanese translated docs.
> >
> > http://www.postgresql.jp/document/9.5/html/
> >
> > Currently "Copyright 1996-2016 The PostgreSQL Global Development
> > Group" is showed on the translated doc (of course in Japanese). What
> > JPUG is wanting is, adding something like "Copyright 2016 Japan
> > PostgreSQL Users Group" to this.
> 
> As I understand it the translation would be copyrighted by the people 
> that do the translation so it is perfectly reasonable to have JPUG hold 
> the copyright for the .jp translation.
> 
> >
> > The reason for this is, "Copyright 1996-2016 The PostgreSQL Global
> > Development Group" may not be effective from the point of Japan laws
> > because "The PostgreSQL Global Development Group" is not a valid
> > entity to be copyright holder according to Japan's laws. To prevent
> > from abuses of the translated docs, JPUG thinks that JPUG needs to add
> > the copyright notice by JPUG to the Japanese translated docs (note
> > that JPUG is a registered non profit organization and can be a
> > copyright holder).
> 
> Considering they are BSD licensed, I am not sure what abuses could be taken?
> 
> Sincerely,
> 
> JD
> 
> -- 
> Command Prompt, Inc.  http://the.postgres.company/
>  +1-503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Everyone appreciates your honesty, until you are honest with them.
> 
> 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Figures in docs

[Ioseph Kim]

On 수, 2016-02-17 at 12:14 +0300, Alexander Lakhin wrote:
> 17.02.2016 09:17, Tatsuo Ishii wrote:
> >> Hi. 
> >>
> >> In DocBook 4.2 sgml dtd, figure tag is supported already.
> >> that was implemented for multi output format.
> > Ok, there's no technical problems with figures then.  MySQL docs has
> > some nice figures. I am jealous.
> The "figure" tag is just a placeholder in the Docbook
> (http://www.docbook.org/tdg/en/html/figure.html).
> The question is what to place inside this tag: "graphic" (not inline),
> "mediaobject/imageobject" (alternative object, supports inline contents
> and SVG), or something else.
> So you surely can insert some picture from an external file (.png,
> .jpg), but if it could contain title or some labels that should be
> translated, it's not a best solution.

I want say, just about figure tag.
sgml document can include external image file. 

in sgml

   

 Some Image
  

   

then make html command generate below html code

Figure E-1. Some Image

so, 
I asked how maintenance that some_image.jpg file.
I think that is so difficult, because new release document might change
these too.
if use svg module for docbook, document sources will are maked very
dirty.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Figures in docs

[Ioseph Kim]

Hi. 

In DocBook 4.2 sgml dtd, figure tag is supported already.
that was implemented for multi output format.

I remember that very old postgresql document has some picture (eg.
system architecture, ERD ...).
when release new version, these might be changed, nevertheless these can
not been.

this proposer is not about xml or sgml.
how can new figures be modified for new documents.

regards ioseph.
 
2016-02-17 (수), 08:26 +0300, Oleg Bartunov:
> 
> 
> On Wed, Feb 17, 2016 at 4:17 AM, Tatsuo Ishii 
> wrote:
> It seems there's no figures/diagrams in our docs. I vaguely
> recall that
> we used to have a few diagrams in our docs. If so, was there
> any
> technical reason to remove them?
> 
> I don't know the reason, but it's shame, we are still in sgml ! 
> 
> We already do our translations (as others) in xml using custom
> scripting.  xml provides us better integration with available tools
> and ability to insert graphics. Last time we asked in -docs about
> moving to xml and Alexander demonstrated acceptable speed of xml
> build, but there were no reply from Peter, who is (?) responsible for
> our documentation infrastructure. Probably, we should just created a
> patch and submit to commitfest.  You can check this thread
> http://www.postgresql.org/message-id/1428009501118.85...@postgrespro.ru
> 
> 
> 
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> 
> 
> --
> Sent via pgsql-hackers mailing list
> (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 
> 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PGCon 2016 call for papers

[Ioseph Kim]

Sorry ^^

2016-01-18 (월), 16:10 +0900, Michael Paquier:
> On Mon, Jan 18, 2016 at 3:29 PM, Ioseph Kim <pgsql...@postgresql.kr> wrote:
> > What can I do for next step?
> 
> (pgsql-hackers is not the right place to ask that, it is a mailing
> list dedicated to the development and discussion of new features)
> 
> Follow the flow here:
> http://www.pgcon.org/2016/papers.php
> And Register here:
> https://papers.pgcon.org/submission/PGCon2016/
> And finally wait to see if your talk is accepted.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PGCon 2016 call for papers

[Ioseph Kim]

Hello, 
I want to speak a proposal on PGCon 2016.
Currently I wrote only title of contents.
Main title is "PostgreSQL in Korea".

That proposal contains

*  Short history of PostgreSQL in Korea (status of korean user group
and theses works)
*  kt (korea telecom) report (for PostgreSQL)
*  ToDo in Korea (of korean user group) 

What can I do for next step?


2016-01-03 (일), 16:58 -0500, Dan Langille:
> In case you've overlooked it, you have about two weeks to submit your 
> proposal.
> 
> PGCon 2016 will be on 17-21 May 2016 at University of Ottawa.
> 
> * 17-18 (Tue-Wed) tutorials
> * 19 & 20 (Thu-Fri) talks - the main part of the conference
> * 17 & 21 (Wed & Sat) The Developer Unconference & the User Unconference 
> (both very popular)
> 
> PLEASE NOTE: PGCon 2016 is in May.
> 
> See http://www.pgcon.org/2016/
> 
> We are now accepting proposals for the main part of the conference (19-20 
> May).
> Proposals can be quite simple. We do not require academic-style papers.
> 
> If you are doing something interesting with PostgreSQL, please submit
> a proposal.  You might be one of the backend hackers or work on a
> PostgreSQL related project and want to share your know-how with
> others. You might be developing an interesting system using PostgreSQL
> as the foundation. Perhaps you migrated from another database to
> PostgreSQL and would like to share details.  These, and other stories
> are welcome. Both users and developers are encouraged to share their
> experiences.
> 
> Here are a some ideas to jump start your proposal process:
> 
> - novel ways in which PostgreSQL is used
> - migration of production systems from another database
> - data warehousing
> - tuning PostgreSQL for different work loads
> - replication and clustering
> - hacking the PostgreSQL code
> - PostgreSQL derivatives and forks
> - applications built around PostgreSQL
> - benchmarking and performance engineering
> - case studies
> - location-aware and mapping software with PostGIS
> - The latest PostgreSQL features and features in development
> - research and teaching with PostgreSQL
> - things the PostgreSQL project could do better
> - integrating PostgreSQL with 3rd-party software
> 
> Both users and developers are encouraged to share their experiences.
> 
> The schedule is:
> 
> 1 Dec 2015 Proposal acceptance begins
> 19 Jan 2016 Proposal acceptance ends
> 19 Feb 2016 Confirmation of accepted proposals
> 
> NOTE: the call for lightning talks will go out very close to the conference.
> Do not submit lightning talks proposals until then.
> 
> See also 
> 
> Instructions for submitting a proposal to PGCon 2016 are available
> from: 
> 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] request patch pg_recvlogical.c, pg_receivexlog.c for nls

[Ioseph Kim]

Hello,

at PostgreSQL version 9.5rc1,
at line 934 in pg_recvlogical.c 

set_pglocale_pgservice(argv[0],PG_TEXTDOMAIN("pg_recvlogical"));

this references invalid catalog file, because pg_basebackup,
pg_recvlogical, pg_receivexlog commands use same catalog file
pg_basebackup.mo

pg_receivexlog.c too.

patch please. 





-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Mailing subscription test

[Ioseph Kim]

Sorry, i can't receive mailing :(


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CP949 for EUC-KR?

[Ioseph Kim]

Hi, I'm Korean.

CP51949 is EUC-KR correct.
so, that defined code is correct too.

But in Korea, EUC-KR code is not good to use all Korean character.
In recent years, many people in Korea use the CP949 code.
MS Windows codepage also is CP949.

- Original Message - 
From: Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp
To: pgsql-hackers@postgresql.org
Sent: Tuesday, April 27, 2010 7:27 PM
Subject: [HACKERS] CP949 for EUC-KR?


I heard pg_get_encoding_from_locale() failed in kor locale.
 
WARNING:  could not determine encoding for locale kor: codeset is CP949
 
 I found the following description in the web:
CP949 is EUC-KR, extended with UHC (Unified Hangul Code).

 http://www.opensource.apple.com/source/libiconv/libiconv-13.2/libiconv/lib/cp949.h
 
 but we define CP51949 for EUC-KR in chklocale.c.
{PG_EUC_KR, CP51949}, /* or 20949 ? */
 
 Which is the compatible codeset with our PG_EUC_KR encoding?
 949, 51949, or 20949? Should we add (or replace) CP949 for EUC-KR?
 
 Regards,
 ---
 Takahiro Itagaki
 NTT Open Source Software Center
 
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Server-side support of all encodings

[Ioseph Kim]

At Korea, Johab code is very old encondig.
by the way, cp949 code page is really used in most environments.

Personally speaking, Johab server code set is not need.
I think that PostgreSQL supports UHC (cp949) server  code set.
This feature will be greet many Korean. :)
Unfortunately, UHC code set have character sequences less then 128 byte.

I tred to patch this problem, but this is not simply. I had gave up. :(


- Original Message - 
From: ITAGAKI Takahiro [EMAIL PROTECTED]

To: Tom Lane [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Monday, March 26, 2007 11:29 AM
Subject: Re: [HACKERS] Server-side support of all encodings




Tom Lane [EMAIL PROTECTED] wrote:

 PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client 
 encodings,
 but we cannot use them as server encodings. Are there any reason for 
 it?


Very much so --- they aren't safe ASCII-supersets, and thus for example
the parser will fail on them.  Backend encodings must have the property
that all bytes of a multibyte character are = 128.


But then, PG_JOHAB have already infringed it. Please see 
johab_to_utf8.map.

Trailing bytes of JOHAB can be less than 128.
It's true that other server-supported encodings use only characters = 
128.


Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[HACKERS] problem of geometric operator in v8.2.1

[Ioseph Kim]

= select @-@ lseg '((0,0),(1,0))';
?column?
--
   1
(1 row)

= select @-@ path '((0,0),(1,0))';
?column?
--
   2
(1 row)

--

It's maybe bug in v8.2.1



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] problem of geometric operator in v8.2.1

[Ioseph Kim]

when @-@ operator used at path type,
below query maybe returns 1.
because this path is just line.


- Original Message - 
From: Tom Lane [EMAIL PROTECTED]

To: Ioseph Kim [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Saturday, February 03, 2007 5:36 AM
Subject: Re: [HACKERS] problem of geometric operator in v8.2.1 




Ioseph Kim [EMAIL PROTECTED] writes:

= select @-@ lseg '((0,0),(1,0))';
 ?column?
--
1
(1 row)



= select @-@ path '((0,0),(1,0))';
 ?column?
--
2
(1 row)



It's maybe bug in v8.2.1


What do you think is wrong with those answers?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] problem of geometric operator in v8.2.1

[Ioseph Kim]

I misunderstood. :)

path '((0,0),(1,0))' is 'closed' path.

in this case, it's maybe operator calculated return length too.

- Original Message - 
From: Ioseph Kim [EMAIL PROTECTED]

To: pgsql-hackers@postgresql.org
Sent: Saturday, February 03, 2007 6:00 AM
Subject: Re: [HACKERS] problem of geometric operator in v8.2.1 




when @-@ operator used at path type,
below query maybe returns 1.
because this path is just line.


- Original Message - 
From: Tom Lane [EMAIL PROTECTED]

To: Ioseph Kim [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Saturday, February 03, 2007 5:36 AM
Subject: Re: [HACKERS] problem of geometric operator in v8.2.1 




Ioseph Kim [EMAIL PROTECTED] writes:

= select @-@ lseg '((0,0),(1,0))';
 ?column?
--
1
(1 row)



= select @-@ path '((0,0),(1,0))';
 ?column?
--
2
(1 row)



It's maybe bug in v8.2.1


What do you think is wrong with those answers?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster