Re: [HACKERS] pg_reorg in core?
(2012/09/22 10:02), Christopher Browne wrote: If the present project is having a tough time doing enhancements, I should think it mighty questionable to try to draw it into core, that presses it towards a group of already very busy developers. On the other hand, if the present development efforts can be made more public, by having them take place in a more public repository, that at least has potential to let others in the community see and participate. There are no guarantees, but privacy is liable to hurt. I wouldn't expect any sudden huge influx of developers, but a steady visible stream of development effort would be mighty useful to a "merge into core" argument. A *lot* of projects are a lot like this. On the Slony project, we have tried hard to maintain this sort of visibility. Steve Singer, Jan Wieck and I do our individual efforts on git repos visible at GitHub to ensure ongoing efforts aren't invisible inside a corporate repo. It hasn't led to any massive of extra developers, but I am always grateful to see Peter Eisentraut's bug reports. Agreed. What reorg project needs first is transparency, including issue traking, bugs, listup todo items, clearfied release schedules, quarity assurance and so force. Only after all that done, the discussion to put them to core can be started. Until now, reorg is developed and maintained behind corporate repository. But now that its activity goes slow, what I should do as a maintainer is to try development process more public and finds someone to corporate with:) Sakamoto -- 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] pg_reorg in core?
(2012/09/21 22:32), Michael Paquier wrote: On Fri, Sep 21, 2012 at 9:33 PM, Daniele Varrazzo mailto:daniele.varra...@gmail.com>> wrote: On Fri, Sep 21, 2012 at 5:17 AM, Josh Kupershmidt mailto:schmi...@gmail.com>> wrote: I haven't submitted it to PGXN as I prefer the original author to keep the ownership. Thanks, I merged your patches with the dev branch for the time being. It would be great to have some input from the maintainers of pg_reorg in pgfoundry to see if they agree about putting it in pgxn. Hi, I'm Sakamoto, reorg mainainer. I'm very happy Josh, Michael and Daniele are interested in reorg. I'm working on the next version of reorg 1.1.8, which will be released in a couple of days. And I come to think that it is a point to reconsider the way to develop/maintain. To be honest, we have little available development resources, so no additional features are added recently. But features and fixes to be done (as Josh sums up. thanks). I think it is a good idea to develop on github. Michael's repo is the root? After the release of 1.1.8, I will freeze CVS repository and create a mirror on github. # Or Michael's repo will do :) I have received some patches from Josh, Daniele. It should be developed in the next major version 1.2. So some of them may not be included in 1.1.8 (caz it's minor versionup), but I feel so appreciated. I think we can discuss further at reorg list. Sakamoto -- 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] patch: SQL/MED(FDW) DDL
sorry for my slow response. (2010/09/24 21:13), Robert Haas wrote: This is a good point. On the one hand, I do agree that the API for simple things like processing CSV files shouldn't be overly complex. So perhaps we could start with a simple API and extend it later. On the other hand, understanding how some of the more complex cases ought to work provides insight into handling the simpler cases. So I think we should aim to have at least a sketch of a design for the whole feature, and then if in phase 1 we want to implement only the easier parts, that's OK. Right. In any case, I should clearify what this API could cover by this patch and what could not. # And also how far I and my collaborator can implement.. As Itagaki points out, we have two types of FDW implementations in progress: flat file wrapper and postgresql wrapper. these items are described in wiki: http://wiki.postgresql.org/wiki/SQL/MED But it may be hard to get what this fdw routines 'could' provide, so I and my collaborator is now summarizing these items to discuss and ask for help. Anyway I think these items are needed to discuss further. - API design that is used in executor for a single external table. - simple FDW implements to clearfy what this API could provide. These items will be shown by my collaborator soon. thanks in advance, SAKAMOTO Masahiko NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center e-mail: sakamoto.masah...@oss.ntt.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
Re: [HACKERS] patch: SQL/MED(FDW) DDL
And this is sample script to play the feature of this patch. It includes: - create foreign data wrapper and foreign server(PG at localhost) - select foreign PostgreSQL table. *Important* This script initializes your database cluster(specified by $PGDATA). Run with care Regards, SAKAMOTO Masahiko NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center e-mail: sakamoto.masah...@oss.ntt.co.jp #!/bin/sh export PGDATABASE=postgres export PGUSER=postgres # re-create database cluster pg_ctl stop -m immediate rm -rf $PGDATA initdb -U postgres # FDW for PostgreSQL requires password authentiaction on non-superuser access mv $PGDATA/pg_hba.conf $PGDATA/pg_hba.conf.org cat > $PGDATA/pg_hba.conf < -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] patch: SQL/MED(FDW) DDL
Hello. This is a proposal patch for SQL/MED for 9.1. At the prev. CF, this patch had so many features to make it hard to review all of them. So I devided it into smaller parts: (1) foreign table DDL support (this proposal): - support for foreign table DDL syntax (CREATE/ALTER FOREIGN TABLE) - Definition of FDW routine interface and system catalogs for it. (2) SELECT support for external PostgreSQL tables. First of all, I'd like to discuss and make agreement on the basic design and its implementation for FDW interface. Comments and ideas would be very appriciated, especially on how system catalog stores the information about foreign tables, server, and user mappings. Detail information are described in the wiki: http://wiki.postgresql.org/wiki/SQL/MED I'll add this item to the CF site. And WIP patch for (2) will be available on the page for how (1) is utilized. - Open Issue: - fdw connection params issue: In this implimentation, foreign table connection params(including passwords) are visible to all users. To avoid it, store them in the user_mapping object, not in foreign server object. # It should be improved, though. - fdw security issue: It depends on how indivisual fdw extensions are designed. I'll focus on it after basic agreement on fdw interface. - prev. CF page: https://commitfest.postgresql.org/action/patch_view?id=326 - code repository: http://repo.or.cz/w/pgsql-fdw.git (branch: foreign_table). repository branches structures is as follows: master +foreign_table: (active) branch for this proposal - foreign_scan: (active) WIP branch for select support +fdw_ddl: (will be obsolute) branch for last CF - dblink - copy_from Thanks in advance, SAKAMOTO Masahiko NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center e-mail: sakamoto.masah...@oss.ntt.co.jp fdw_table20100914.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
