nyuuzyou/wikis huggingface dataset:
Informacioón de Desarrollo

__NOTOC__
Esta área incluye la documentación de desarrollo orientada sobre los aspectos de desarrollo de PostgreSQL. Por favor, visite el área de desarrollo del sitio web de PostgreSQL developer areapara obtener más información sobre el desarrollo de PostgreSQL. Usted puede encontrar la mayoría de los desarrolladores en #postgresql on Libera. Una lista de nicks de IRC con sus respectivos nombres del mundo real se puede encontrar aqui.
==PostgreSQL 9.1 - Desarrollo Activo==
* PostgreSQL 9.1 Plan de Desarrollo
* PostgreSQL 9.1 Open Items
==PostgreSQL 9.0 - Release Preparation==
* PostgreSQL 9.0 Open Items
* 9.0 Alpha Release Feature List
==Proceso de Desarrollo==
* Todo list
* Unofficial Todo Detail
* Submitting a Patch
* Reviewing a Patch
* Round-robin Patch Review
* Running a CommitFest
* Committing con Git
== Recursos para Desarrolladores ==
* Developer FAQ
* Regression test authoring
* HOWTO Alpha and Beta Test PostgreSQL
* Trabajando con Git
* Trabajando con CVS (obsoleto)
* Trabajando con Eclipse (usando CVS)
* Fixing shift/reduce conflicts in Bison
* Procedural Language Matrix
* Feature Matrix
* PostgreSQL Coding
* Development docs (updated every 5 minutes)
== Projectos y Planning ==
* Open CommitFest - New patch submissions for 9.1
* CommitFest
* PostgreSQL 8.4
* PgCon 2009 Developer Meeting
* PgCon 2008 Developer Meeting
* Development projects - links to individual projects
Category:CommitFest
In-place upgrade

__NOTOC__
Note that pg_upgrade is distributed with PostgreSQL, and can accomplish most of these desires (in particular with the --link option). That should be the first stop of people wishing to do an in-place upgrade. 
The rest of this current page is generally of historical interest only.
This page goes over the technical challenges in converting older version PostgreSQL databases to newer ones, as outlined in the associated presentation PostgreSQL upgrade project.
== Descriptions ==
== Goals ==
A long term overview of what one user would like to see...
In-place upgrade means no need to copy user data to upgrade between software versions (not copying system catalogs would be ideal, however even o large databases, catalog size tends to not be prohibitive). Upgrades should allow for an online system after the upgrade, meaning we have full read/write capabilities to the data. Format changes should be copy-on-write, rather than copy-on-read, to prevent excessive i/o needs after upgrade (think large tables). A manual command to force update to the physical format would be nice (clearly anything like cluster/vacuum full would do this, though perhaps a vacuum upgrade would be warranted as well)
== Sub projects ==
In-place upgrade is very complex project. Fortunately, it can be split into several sub projects. The storage and catalog sub-projects are most important and they are base for others.
 
=== Storage ===
Storage upgrade focuses on upgrade on disk formats from old version to the new one. All data in PostgreSQL are stored on pages. Page size is usually 8kB. The size is defined by BLCKSZ constant which can be modified only in compilation time. The goal is to convert pages from old format to the new format without internal structures dependency break. See storage dependency graph:
TODO: dependency graph
On disk format version is specified by PG_PAGE_LAYOUT_VERSION (PLV) (bufpage.h). You can see detail here.
Following structures are part of page layout:
* PageHeaderData (bufpage.h)
* HeapTupleHeaderData (htup.h)
* IndexTupleHeaderData (itup.h)
* ItemIdData (itemid.h)
Each structures also contains inner structures and usually they have flag field(s).
Issues
* varlena encoding change (introduced in PLV 4 - PG8.3)
* composite data types - composite data types share data structure with HeapTupleHeaderData
* size expansion - converted data need not fit on page 
=== Access Methods (indexes) ===
=== Catalog ===
=== Data types ===
== Other in-place upgrade resources ==
* pg_migrator
* pg_upgrade.sh
* Presentation in Prato Italy, October 2008
Category:PostgreSQL 8.4
Category:Historical information
Insertion Sort

This is a very simple example of how to use Recursive CTE to implement the (inefficient) insertion sort algorithm by me
with recursive isort(arr, position, sorted_count) as (
 select ARRAY[7,3,6,9,0,42,9], 1, 1
 union all
 select case when position=1 or arr[position]>=arr[position-1] then arr
 else arr[1:position-2]||arr[position]||arr[position-1]||arr[position+1:array_length(arr, 1)] end,
 case when position=1 or arr[position]>=arr[position-1] then sorted_count+1
 else position-1 end,
 case when position=1 or arr[position]>=arr[position-1] then 1 else 0 end + sorted_count
 from isort
 where sorted_count <= array_length(arr,1))
select * from isort;
If you just want the sorted array, you could use select arr from isort where sorted_count=array_length(arr,1)+1 instead of select * from isort.
INSERT RETURNING vs Partitioning

A common complaint with the normal approach of using a BEFORE INSERT trigger for partitioning is that the return NULL; in the trigger prevents the normal functioning of INSERT … RETURNING from working.
One workaround is to revert to using currval() for finding inserted ids; this unfortunately only works for single-row inserts. Another workaround is to let the insert into the parent table succeed, but then immediately delete the row again; this has obvious drawbacks.
Here is an example of an alternative workaround, which uses a view with an INSTEAD trigger:
-- create a simple partitioned table
create table mydata_real (id serial, rowdate date, content text);
create table mydata_real_y2015 (check (rowdate >= '2015-01-01' and rowdate < '2016-01-01')) inherits (mydata_real);
create table mydata_real_y2016 (check (rowdate >= '2016-01-01' and rowdate < '2017-01-01')) inherits (mydata_real);
-- block attempts to insert on the actual parent table
create function mydata_nope() returns trigger language plpgsql
as $f$
 begin
 raise exception 'insert on wrong table';
 return NULL;
 end;
$f$;
create trigger mydata_nope before insert on mydata_real execute procedure mydata_nope();
-- create the view, which will be used for all access to the table:
create view mydata as select * from mydata_real;
-- need to copy any defaults from mydata_real to the view
alter view mydata alter column id set default nextval('mydata_real_id_seq');
-- this is the actual partition insert trigger:
create function mydata_partition() returns trigger language plpgsql
as $f$
 begin
 case extract(year from NEW.rowdate)
 when 2015
 then insert into mydata_real_y2015 select NEW.*;
 when 2016
 then insert into mydata_real_y2016 select NEW.*;
 else
 raise exception 'date % out of range', NEW.date;
 end case;
 return NEW;
 end;
$f$;
create trigger mydata_partition instead of insert on mydata
 for each row execute procedure mydata_partition();
-- sample insert
insert into mydata(rowdate,content)
 values ('2015-01-10','foo'),('2015-12-12','bar'),('2016-02-02','baz')
 returning id;
Category:Table_partitioning
Instalación en Linux

=== A partir de los paquetes de una distribución ===
* Instalar en Debian, Ubuntu o distro que utilice apt:
 apt-get install postgresql-8.3 postgresql-client-8.3 postgresql-contrib-8.3
* Instalar en Centos:
 yum install postgresql-8.1.9-1.el5.i386.rpm postgresql-contrib-8.1.9-1.el5.i386.rpm postgresql-libs-8.1.9-1.el5.i386.rpm 
 postgresql-docs-8.1.9-1.el5.i386.rpm postgresql-server-8.1.9-1.el5.i386.rpm
* Para Centos en maquina x86_64
 yum install postgresql-8.1.9-1PGDG.x86_64.rpm postgresql-contrib-8.1.9-1PGDG.x86_64.rpm postgresql-libs-8.1.9-1PGDG.x86_64.rpm 
 postgresql-docs-8.1.9-1PGDG.x86_64.rpm postgresql-server-8.1.9-1PGDG.x86_64.rpm
=== Creando el primer superusuario ===
Esto solo es necesario cuando se instala desde una distribución y durante el proceso de instalación no se solicita contraseña para el usuario por defecto que se crea
que se llama postgres, lo que haremos será autenticarnos como el usuario root primero, luego como el usuario postgres (si es que deseamos que el usuario postgres conserve su contraseña aleatoria) y finalmente crear una base de datos de prueba y un usuario.
¡¡¡ASEGURESE QUE ESTÁ CORRIENDO EL SERVICIO DE POSTGRES ANTES DE CREAR UN USUARIO!!! 
Primer superusuario con logging admin
 createuser -s -P -e admin
Correr el servicio:
en Ubuntu/Debian:
 /etc/init.d/initdb start -- Inicializando el cluster
 /etc/init.d/postgresql start -- Echar andar el gestor
en Fedora/CentOS:
 service postgresql initdb -- Inicializando el cluster
 service postgresql start -- Echar andar el gestor
1- Autenticarnos como usuario root
en Ubuntu/Debian:
 sudo su root
en Fedora/CentOS:
 su root
2- Autenticarnos como usuario postgres
Ya que estamos como root el autenticarnos como cualquier usuario no nos pedira contraseña
en Ubuntu/Debian:
 su postgres
en Fedora/CentOS:
 su - postgres 
3- Crear la base de datos de prueba
 createdb test1
* Conectar con la Base de Datos de prueba
 psql -d test1
 Welcome to psql 8.1.9, the PostgreSQL interactive terminal.
 Type: \copyright for distribution terms
 \h for help with SQL commands
 \? for help with psql commands
 \g or terminate with semicolon to execute query
 \q to quit 
 test1=# \q -- Salir de la consola
Category:Install
Instalación interactiva en Windows

== Introducción ==
Este es un instructivo de la instalación de PostgreSQL en windows con el instalador PgInstaller (no aplica al instalador OneClickInstaller).
Para más información, ver sitio de:
* PostgreSQL Installer (inglés)
* Proyecto de Instalador en Español
== Pasos para instalar PostgreSQL ==
* Bajar el instalador PgInstaller: desde el sitio web www.postgresql.org
** Instalador oficial en inglés
** Instalador beta no oficial en español (usar sólo para pruebas)
* Descomprimir el archivo .zip y ejecutar el instalador (postgresql-8.x.msi) 
* Recomendaciones
* En windows Vista Home o Premiun, se debe desactivar el UAC , y luego ejecutar el siguiente comando net User Administrador /active:Yes
* Esto es importante dado que la instalacion en Vista se debe hacer con el Usuario Administrador.
* Si ud. requiere realizar una reinstalación limpia, desinstale el Software desde el panel de Control
* Borre la cuenta postgres con el comando net user postgres /deleted
# En "Selección del lenguaje": English o Español (beta), Next (siguiente) >
# En Pantalla de introducción, leer y Next (siguiente) >
# En Pantalla de bienvenida, leer y Next (siguiente) >
# En "Installation Options" (Opciones de Instalación), marcar "National Lenguaje Support" (Soporte para Lenguaje Nacional), Next (siguiente) >
# En "Service configuration" (Configuración del servicio), 
## Account name (nombre de la cuenta): postgres,
## No se debe digitar ninguna clave, dado que el proceso de instalación genera de manera automática una clave randomica
## Next (siguiente) >
# En "Initialize database cluster" (Inicializar clúster de base de datos),
## Locale (Configuración Regional): ES_AR (o el que corresponda)
## Encoding (Codificación): UTF8
## Superuser name (Nombre del "superusuario" administrador): postgres
## Password (Contraseña del "superusuario" administrador): ingresar una contraseña para la administración
## Password (again): idem anterior
## Next (siguiente) >
# Next (siguiente) > hasta que termina
Category:Español
Integer to Text

This function converts an integer between 1 and 999999999 to uppercase English text:
CREATE FUNCTION to_text(integer) RETURNS text LANGUAGE sql IMMUTABLE STRICT AS
$$SELECT CASE WHEN $1<1 THEN NULL
 WHEN $1=1 THEN 'ONE'
 WHEN $1=2 THEN 'TWO'
 WHEN $1=3 THEN 'THREE'
 WHEN $1=4 THEN 'FOUR'
 WHEN $1=5 THEN 'FIVE'
 WHEN $1=6 THEN 'SIX'
 WHEN $1=7 THEN 'SEVEN'
 WHEN $1=8 THEN 'EIGHT'
 WHEN $1=9 THEN 'NINE'
 WHEN $1=10 THEN 'TEN'
 WHEN $1=11 THEN 'ELEVEN'
 WHEN $1=12 THEN 'TWELVE'
 WHEN $1=13 THEN 'THIRTEEN'
 WHEN $1=14 THEN 'FOURTEEN'
 WHEN $1=15 THEN 'FIFTEEN'
 WHEN $1=16 THEN 'SIXTEEN'
 WHEN $1=17 THEN 'SEVENTEEN'
 WHEN $1=18 THEN 'EIGHTEEN'
 WHEN $1=19 THEN 'NINETEEN'
 WHEN $1<100 THEN CASE
 WHEN $1/10=2 THEN 'TWENTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=3 THEN 'THIRTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=4 THEN 'FOURTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=5 THEN 'FIFTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=6 THEN 'SIXTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=7 THEN 'SEVENTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=8 THEN 'EIGHTY' || COALESCE(' ' || to_text($1%10), )
 WHEN $1/10=9 THEN 'NINETY' || COALESCE(' ' || to_text($1%10), )
 END
 WHEN $1<1000
 THEN to_text($1/100) || ' HUNDRED' ||
 COALESCE(' AND ' || to_text($1%100), )
 WHEN $1<1000000
 THEN to_text($1/1000) || ' THOUSAND' ||
 CASE WHEN $1%1000 < 100
 THEN COALESCE(' AND ' || to_text($1%1000), )
 ELSE COALESCE(' ' || to_text($1%1000), )
 END
 WHEN $1<1000000000
 THEN to_text($1/1000000) || ' MILLION' ||
 CASE WHEN $1%1000000 < 100
 THEN COALESCE(' AND ' || to_text($1%1000000), )
 ELSE COALESCE(' ' || to_text($1%1000000), )
 END
 ELSE NULL
 END$$;
Category:SQL
Intel vs. AMD Processors

Current generation AMD and Intel processors are pretty close in performance, but guessing which will work better involves a complicated mix of both CPU and memory
issues. AMD's NUMA architecture does some things better, and Intel's memory access takes a second hit in designs that use FB-DIMMs. But Intel has enough of an
advantage on actual CPU performance and CPU caching that current designs are usually faster regardless.
For an interesting look at the low-level details here, the current mainstream parts are compared at http://techreport.com/articles.x/11443/13 and a similar comparison
for the just released quad-core Opterons is at http://techreport.com/articles.x/13176/12
Nowadays (mid-2008) Intel vs. AMD is tight enough that in the context of a database application that it shouldn't be a major driver in your purchasing decision process. On a real server, you should be more worried about how good the disk controller is, what the expansion options are there, and relative $/core. In the x86/x64 realm, CPU architecture is not a huge issue right now for most situations where you're running a database.
Category:Performance
Inverse Distribution Functions

= Inverse Distribution Functions =
Defined in the SQL standard in Section 10.9 <aggregate function>,
inverse distribution functions open whole new vistas both of
reporting and of implementation challenges.
= Vistas of Reporting =
* MEDIAN! YAY!
* N-tiles (continuous and discrete)
* Many others.
= Implementation Challenges =
* Parser
** Mostly done. Thanks, Atri Sharma!
** WITHIN GROUP clause
** Changes parser functions to work with new type of functions
** Adds a new type for identification of ordered set functions from function lookup
** Modifies pg_proc
** Currently working on type coercion
** Changes Aggref struct to identify ordered set functions.No new struct for ordered set functions since they share a lot with aggregate functions.
** Overloaded functions support
* Planner/Optimizer
** In progress
** Really applies atop FILTER, not yet in master.
** New element in ProcedureCreate
* Executor
** New way to do aggregates: transition function now optional.
** Directly go to final function, skipping transition functions for ordered set functions.
Is distinct from

Pg supports two comparison statements IS DISTINCT FROM and IS NOT DISTINCT FROM, these essentially treat NULL as if it was a known value, rather than a special case for unknown.
Mnemonic: DISTINCT means different which is what '<>' tests for 
== Syntax ==
 SELECT foo,bar FROM table WHERE foo IS DISTINCT FROM bar;
 SELECT foo,bar FROM table WHERE foo IS NOT DISTINCT FROM bar;
== Truth Table ==
\pset null '<<NULL>>'
select a.a, b.b, a.a IS DISTINCT FROM b.b AS "Is Distinct From" FROM (VALUES (1), (2), (NULL)) AS a (a), (VALUES (1), (2), (NULL)) AS b (b);
 a | b | Is Distinct From 
----------+----------+------------------
 1 | 1 | f
 1 | 2 | t
 1 | <<NULL>> | t
 2 | 1 | t
 2 | 2 | f
 2 | <<NULL>> | t
 <<NULL>> | 1 | t
 <<NULL>> | 2 | t
 <<NULL>> | <<NULL>> | f
select a.a, b.b, a.a IS NOT DISTINCT FROM b.b AS "Is Not Distinct From" FROM (VALUES (1), (2), (NULL)) AS a (a), (VALUES (1), (2), (NULL)) AS b (b);
 a | b | Is Not Distinct From 
----------+----------+----------------------
 1 | 1 | t
 1 | 2 | f
 1 | <<NULL>> | f
 2 | 1 | f
 2 | 2 | t
 2 | <<NULL>> | f
 <<NULL>> | 1 | f
 <<NULL>> | 2 | f
 <<NULL>> | <<NULL>> | t
== Writing with CASE statements ==
Both of these sql comparison macros can be written with a CASE statement:
foo IS NOT DISTINCT FROM bar
CASE
 -- Act like a normal '=' on non-null values.
 WHEN foo IS NOT NULL AND bar IS NOT NULL
 THEN foo = bar
 -- foo = 'notnull' , bar = 'null' ; then foo <> bar so false
 WHEN foo IS NOT NULL AND bar IS NULL
 THEN false
 -- foo = 'null' , bar = 'null' ; then foo = bar so true
 WHEN foo IS NULL AND bar IS NULL
 THEN true
 ELSE false
END
foo IS DISTINCT FROM bar
CASE
 -- Act like a normal '<>' on non-null values.
 WHEN foo IS NOT NULL AND bar IS NOT NULL
 THEN foo <> bar
 -- foo = 'notnull' , bar = 'null' ; then foo <> bar so true
 WHEN foo IS NOT NULL AND bar IS NULL
 THEN true
 -- foo = 'null' , bar = 'null' ; then foo = bar so false
 WHEN foo IS NULL AND bar IS NULL
 THEN false
 ELSE true
END
== Determining different data in tables ==
Lets say you have two tables, t1, and t2, and they both have columns "foo","bar","baz" and you want to see all rows that are in t1, that aren't in t2. Normally, if you wanted the effect of '=' you could make this really simple:
SELECT foo,bar,baz
FROM t1
LEFT OUTER JOIN t2 USING (foo,bar,baz)
WHERE t1.foo IS NULL
USING (foo,bar,baz) is just a macro for: t1.foo = t2.foo AND t1.bar = t2.bar AND t1.baz = t2.baz
However, if you wanted the treat-null-as-a-known-value alternative you would need: IS NOT DISTINCT FROM. The task because slightly more verbose and daunting when joining a table, because there are no shorthands for the IS NOT DISTINCT FROM form.
SELECT t1.foo,t1.bar,t1.baz
FROM t1
LEFT OUTER JOIN t2 ON (
 t1.foo IS NOT DISTINCT FROM t2.foo
 AND t1.bar IS NOT DISTINCT FROM t2.bar
 AND t1.baz IS NOT DISTINCT FROM t2.baz
)
WHERE ( t2.foo IS NULL )
Category:SQLCategory:FAQ
Issue 1

=content=
投稿请寄 enthend at 163.com
==新闻==
#PostgreSQL Maven Tom Lane Heads to Salesforce
==9.3 特刊==
#PostgreSQL 9.3 begins beta cycle
#Postgres 9.3 feature highlight timeline switch of slave node without archives
#PostgreSQL 9.3 新特性预览 —— JSON 操作
==博客精选==
#PostgreSQL Proirity
==热门问题==
#PostgreSQL 高可用的实现方式
==应用技巧==
#Instagram 对 Postgres 性能调校的 5 个小技巧
#PostgreSQL的执行计划分析
==应用案例==
#Scaling Threaded Comments on Django at Disqus
==内核==
#postgresql代码结构
==互动问答==
#（通过投稿提问）
Jabber

== Jabber Server ==
If you have an account on the community jabber server with Pidgin, make sure to use:
* Advanced
** Require SSL/TLS checked
** Force old (port 5223) SSL checked
** Allow plaintext auth over unencrypted screens unchecked
** Connection port: 5223
** Connect Server: jabber.postgresql.org
** File transfer proxies: <not needed>
Category:Community
Japan PostgreSQL Developer Meetup

日本の開発者のイベントについてまとめています。
 
# 	Event	Date	City	Place	Activities
10	TBD 	TBD 	TBD 	TBD 	TBD
 
#	Event 	Date 	City 	Place 	Activities
9	Dieu de la guerre 	7 Mar 2019 	Tokyo	Tamachi 	Unconference
8	Le Retour des Dieux 	16 Nov 2018	Tokyo	Kamata 	Unconference
7	Saison des feuilles 	21 MAY 2018	Tokyo	Ikebukuro 	Unconfernece
6	Etude "Nouvelle Lune" 	23 FEB 2018	Tokyo	Kamata 	Unconfernece
5	Etude "le vent d'hiver" 	15 NOV 2017	Tokyo	Shinbashi 	Unconfernece
4	Vers le nouveau monde - the Mayflower	11 MAY 2017	Tokyo	Shinbashi 	Unconfernece
3	PG10 Final Sprint 	9 FEB 2017 	Tokyo	Nishi-Azabu	Unconfernece
2	JPDG PostgreSQL Wizard Rallye 	31 OCT 2016	Tokyo	Jinbocho 	Unconfernece
1	Japan PostgreSQL Developer Meetup 	27 APR 2016	Tokyo	Meguro 	Unconfernece
Japan PostgreSQL Developer Meetup 2

= Date & Time =
* 31 October, 2016
* 12:00 - 17:00
= Location =
* Jinbocho | EDITORY Jinbocho
* http://www.editory.jp/map/
= RSVPs =
== Developers (alphabetical order) ==
* Amit Langote
* Aya Iwata
* Daisuke Higuchi
* Etsuro Fujita
* Kohei Kaigai
* Kyotaro Horiguchi
* Taiki Kondo
* Takayuki Tsunakawa
* Tatsuo Ishii
* Tatsuro Yamada
* Masahiko Sawada
* Masao Fujii
* Michael Paquier
* Vinayak Pokale
* Yoshifumi Masunaga
* Yugo Nagata
* Yusuke Egashira
== Staff ==
* Kaori INABA
* Hitoshi HEMMI
* Mark HISADA
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 14:00：What to discuss today?
* 14:00 - 16:30：Unconference style discussion
* 16:30 - 17:00：Cleanup
* 17:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* Facilities
** WiFi
** Projector and Screen(120inch)
** Kitchen
= Agenda =
# 
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 3

= Date & Time =
* 9 February, 2017
* 12:00 - 17:00
= Location =
* Nishi-Azabu| STUDIO TRON
* http://studiotron.jp/en/index.php?access
= RSVPs =
== Developers (alphabetical order) ==
* Amit Langote
* Aya Iwata 
* Ayumi Ishii
* Daisuke Higuchi
* Eiji Seki
* Etsuro Fujita
* Kohei Kaigai
* Kyotaro Horiguchi
* Masahiko Sawada
* Masao Fujii
* Michael Paquier
* Taiki Kondo
* Takayuki Tsunakawa
* Tatsuo Ishii
* Tatsuro Yamada
* Vinayak Pokale
* Yoshifumi Masunaga
* Yugo Nagata
* Yuzuko Hosoya
* Yusuke Egashira
== Staff ==
* Hitoshi HEMMI
* Kaori INABA
* Mark HISADA
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 14:00：What to discuss today?
* 14:00 - 16:30：Unconference style discussion
* 16:30 - 17:00：Cleanup
* 17:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* Facilities
** WiFi
** Projector 
** Kitchen
= Agenda =
# 
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 4

= Date & Time =
* 11 May 2017
* 12:00 - 18:00
= Location =
* New Shinbashi Coworking (ニュー新橋コワーキング: 新橋駅前)
** New Shinbashi Building, 3rd floor room 305C
** http://www.nscow.com/
= RSVPs =
== Developers (alphabetical order) ==
* 	Amit Langote
* 	Daisuke Higuchi
* 	Eiji Seki
* 	Etsuro Fujita
* 	Kohei Kaigai
* 	Kyotaro Horiguchi
* 	Masahiko Sawada
* 	Masanori Oyama
* 	Michael Paquier
* 	Minoru Nakamura
* 	Ryoji Kawamichi
* 	Taiki Kondo
* 	Tatsuo Ishii
* 	Tatsuro Yamada
* 	Vinayak Pokale
* 	Yoshifumi Masunaga
* 	Yugo Nagata
* 	Yusuke Egashira
* 	Yuzuko Hosoya
 Unfortunately the date does not meet everyone's availability:
 we tried it, but we couldn't. To whom cannot make it, 
 we are very sorry, and hope you come if your schedule changes.
 残念ながら皆さま全員のスケジュールに合わせることができませんでした。
 現時点で参加が難しい方も、もし予定が変わった時は是非ご参加ください。
== Staff ==
* Hitoshi HEMMI
* Mark HISADA
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* WiFi
* Projector
* Whiteboard 
* Kitchen
= Agenda =
# SCRAM, encore - Michael Paquier
# Order of WAL during replication - Takeshi Ideriha
# ECPG enhancement - Vinayak Pokale
# PostgreSQL Vietnam - Taiki Kondo
# Postgres Security - Masanori Oyama
# Replication - Masahiro Sawada
= Meeting notes =
back to Japan PostgreSQL Developer