[HACKERS] Contrib modules documentation online
I've been working on converting the current README files for all contrib modules into sgml and add it to the documentation. There are still some fixes to do but i'd like to have some feedback. Indeed, it wasn't agreed to have all if any of the modules together with the core documentation. You can see the docs on [1] in chapter VIII. If you think these could be a good addition, please fill free to comment on how you think sections should be organized to be consistent and easy to read. [1] http://www.nan-tic.com/ftp/pgdoc ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Contrib modules documentation online
I'm very strongly in favor of having this documentation. However, I think it might make sense to put Contrib Modules as a section under either Reference or Appendices. Also, I don't think it's necessary to make each command option a separate subchapter, but I can see how that would be hard to avoid in an automated system. It's not an automated system, README files have different structures so it's all manual work. That's why I asked how you think it should be organized. Anyone else thinks we should put it in Reference or Appendixes? About command options if done different things, it depends on the module I need to revisit this. I also think one command per subchapter isn't very handy. There's also the install issue. By now it's on the introduction of the chapter. And I've repeated it in some of the modules, not all. Do you think it be better put the exact instructions for compiling and installing for each one? What about 'extra' notes, such us some performance tests, and so one. Some of the notes should probably stay in the README files, just like the README files that can be found in some dirs of core. So I'd keep information targeted to developers into the README's and general info into the main doc. Guys, would it be out of the question to do this in 8.3? Please please? I will try to have everything before 8.3. I'd like it gave very little or no work to core developers. If so many people is interested you can help me revise it before the final version. By the way, if somebody has updated any of the contrib README files recently, please send me an e-mail and I'll check if I have the last changes in. -- Albert Cervera i Areny http://www.NaN-tic.com ---(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
Re: [HACKERS] Patch : seq scan readahead (WIP)
A Dissabte, 8 d'agost de 2009, Pierre Frédéric Caillaud va escriure: I guess it would need some experimenting with the values, and a per-tablespace setting, but since lots of people use Linux Software RAID1 on servers, this might be interesting... You guys want to try it ? Your tests involve only one user. What about having two (or more) users reading different tables? You're using both disks for one user for a 35% performance gain only... Patch attached. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 -- 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] Alpha 1 release notes
A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure: OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. (reStructuredText, if you want to play around) Maybe I'd be interesting to add development docs URL [1] so testers can easily find the syntax of new features, or given that they'll be downloading the alpha tarball they should use that documentation? [1] http://developer.postgresql.org/pgdocs/postgres/index.html -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 -- 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] next CommitFest
A Dijous, 12 de novembre de 2009, Euler Taveira de Oliveira va escriure: Simon Riggs escreveu: So, I propose that we simply ignore patches from developers until they have done sufficient review to be allowed to develop again. Is it really impolite for a first-contributor, no? I don't think so, as long as it's properly explained. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 -- 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] [FINALLY] the TODO list has migrated to Wiki
A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. I hereby kindly request the WWW team to update any references to point to the new address; perhaps install a redirection in http://www.postgresql.org/docs/faqs.TODO.html to the new location. The move has been approved by Bruce, the current maintainer. I hope that he continues to maintain the new version. While many details have been sorted out during the move, being a wiki there is nothing set in stone. Feel free to do changes like improve the markup or the templates so that things look better (after appropriate discussion), but if you intend to make changes like mark items completed, add new items, or remove items, please email pgsql-hackers as has been Bruce's tradition. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] [FINALLY] the TODO list has migrated to Wiki
A Divendres 22 Agost 2008, Bruce Momjian va escriure: Albert Cervera i Areny wrote: A Dimecres 20 Agost 2008, Alvaro Herrera va escriure: Hi, Thanks to Brendan Jurd, who spent a lot of effort in creating useful Mediawiki templates, we now have moved the TODO list to the Wiki site. The new official location for the TODO list is here: http://wiki.postgresql.org/wiki/Todo:Todo Any chance of changing Easier and Done marks to others easier to find by a simple search with the browser? Maybe [E] and [D] would do. The old list had the same problem IMHO. The current idea Brendan has is to use a green circle for easy and a check mark for done. That doesn't make it easily searchable. Maybe I'm the only one, but every now and then I take a look at it, and there's no fast way of seeing what items have been done (and marked as easier). -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] [FINALLY] the TODO list has migrated to Wiki
A Divendres 22 Agost 2008, Alvaro Herrera va escriure: Alvaro Herrera escribió: They did not merge with the text, but they were not searchable. May I suggest using the text [easy] and [done] instead? That way, it is searchable, and they don't merge with the text. I just made this change. What I now notice is that both markers are visually not very different. I don't know if this is something worth fussing about. (Maybe the addition of icons as Brendan was suggesting would be sufficient visual clue.) Thanks. Maybe setting [easy] in orange and [done] in green would solve that too. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
A Dimarts 09 Octubre 2007, Joshua D. Drake va escriure: Contrib is just a dead zone for the user populous. Most people consider it unsupported *stuff* with no particular purpose (regardless of the real meaning). I think no visible documentation is the reason for this misconception and 8.3 will provide contrib documentation together with core docs. Let's see what happens then... -- Albert Cervera i Areny http://www.NaN-tic.com ---(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
Re: [HACKERS] 8.3 full text search docs
Andy,
note that documentation is discussed in the pgsql-docs list and patches
usually are submitted to the pgsql-patches list. Nice to see both new
sections, by the way.
A Diumenge 14 Octubre 2007, andy va escriure:
I have two doc updates I'd like to offer. I see we have two example
sections: creating rule-based dict's and creating parsers. When I was
starting I would have liked to see an example usage.
I'd like to offer: example usage and Upgrading.
This is my first draft, if anyone has suggestions I'd be interested in
hearing them. Also, I'm not sure where or who to send this to, so I
hope -hacker is ok.
- Example Usage -
Staring a new project with Full Text Searching is easy. There is
nothing to install anymore, its all built in (in fact, don't install the
contrib module tsearch2 because it will conflict with the tsearch2 built
into the core).
We need to add a new column of type tsvector to the table you'd like to
search. In this example we'll use a table called notes. If your table
exists use:
alter table notes add searchvec tsvector;
If not use:
create table notes (
rowid integer,
note text,
searchvec tsvector
);
The searchvec column is what we will use for searching, so you probably
want to create an index on it... from another place in the manual:
(http://www.postgresql.org/docs/8.3/static/textsearch-indexes.html)
GiST indexes are very good for dynamic data and fast if the number of
unique words (lexemes) is under 100,000,
GIN indexes are best for static data with +100,000 lexemes.
For our example, I'll create a gist index:
create index notesvec on notes using gist(searchvec);
If you have existing data, we need to fill the searchvec column:
update notes set searchvec = to_tsvector(note);
After the update, any rows are inserted or updated will not have their
searchvec column set automatically, for that we need to create a trigger:
create trigger notevecupdate
before insert or update on notes
for each row
execute procedure
tsvector_update_trigger(searchvec, 'pg_catalog.english', note);
Some data:
insert into notes(rowid, note) values(1, 'this is a test');
insert into notes(rowid, note)
values(2, 'I do not like green eggs and ham');
insert into notes(rowid, note) values(3, 'the cat in the hat');
insert into notes(rowid, note)
values(4, 'rage against the dying of the light');
And now we can query it:
select * from notes where searchvec @@ to_tsquery('light');
or
select * from notes, to_tsquery('test') as q where searchvec @@ q;
writing it this way lets you reuse the tsquery q like this:
select note, ts_rank(searchvec, q)
from notes, to_tsquery('test') as q
where searchvec @@ q
order by ts_rank(searchvec, q);
- Example Usage -
- Upgrade from prior versions -
When tsearch2 was put into core, some functions and types were renamed,
among other things. A simple backup and restore will not work to
migrate your database from versions below 8.3 to 8.3.
In general, the way to do it is backup all your data without the
tsearch2 stuff, restore just the data, then recreate the tsearch2 stuff
by hand.
(Its easier to think of this as an upgrade from tsearch2 to tsearch3,
but without the whole renaming it to tsearch3 thing)
To make it a little easier, there is a way using the pg_restore to
selective restore everything that is not in the old tsearch2.
First you must use pg_dump -Fc to backup your existing database.
Then we will create an item list of things we want to restore using this
perl script. It will strip out all the things that look like tsearch2,
and return (to stdout) a list of things you should restore.
For example:
pg_dump -Fc -h oldserver -f ubberbase.bak ubberbase
perl maketoc.pl ubberbase.bak toc
# now restore just the items in toc
pg_restore -Fc --create -d postgres --use-list toc -f ubberbse.bak
There is one thing that will fail, that's the trigger you used to update
the tsvector column. Its because the function tsearch2 was renamed to
tsvector_update_trigger. You'll need to recreate the trigger by hand.
Now that the structures and data are restored, you'll need to go through
and redo the tsearch2 stuff by hand.
After you get the database fixed up, you'll also need to update your
client programs (php, perl, etc). For the most part, just renameing
things (like rank to ts_rank) should be all that's required.
Oleg Bartunov has an incomplete list of items that have been renamed:
http://www.sai.msu.su/~megera/wiki/Tsearch2_83_changes
- Upgrade from prior versions -
--
Albert Cervera i Areny
http://www.NaN-tic.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Including Snapshot Info with Indexes
A Dissabte 13 Octubre 2007, Gokulakannan Somasundaram va escriure: Even otherwise we are recommending Indexes with snapshot as an option. We are not replacing the current index scheme. So if someone feels that his database should run on lesser disk space, let them create the normal index. If he feels he can afford to have more redundant disk space, then he can create indexes with snapshots. We are reducing random I/Os at the cost of extra disk space. So definitely that's a good. But tech folks like us can better decide on something based on experiments, as Tom has pointed out. So let's see whether Indexes with snapshot is worth the trade-off in space. There's also LucidDB [1], another open souce column based data base. But if you look at the features section in their web page, you'll see they use page-level multi-versioning. So they are avoiding the need for storing snapshot information for each tuple, I think that has to be kept in mind. I'd really like that PostgreSQL could gain some features ala Column Based databases, so the administrator could choose how he wants to use the database, but I don't think we'll be able to compete with them if they store snapshot informatin per page, and we're storing it per tuple, for example. So any step in this directoy will probably mean understanding the decisions they've made in their architectures. [1] http://www.luciddb.org/ -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Ready for beta2?
A Diumenge 21 Octubre 2007, Bruce Momjian va escriure: We have had very few beta1 issues. I am thinking we should release beta2 next week and perhaps accelerate beta and consider a final release in November rather than December. Because of the length of our feature freeze it is possible we are not going to have as many beta bugs. I want to send a patch for the contrib modules by late sunday (europe here ;). I'm doing some cleanup and organizing it a bit better and I think somebody expected these docs to be in the second beta... -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] WORM and Read Only Tables (v0.1)
Read-Only Tables Postgres supports the concept of freezing tuples, so they can live forever within the database without needing further writes. Currently there is no command that will guarantee that a table has been completely frozen. This makes it difficult to reliably write data files to WORM media for longer term archiving. (WORM means Write-Once, Read-Many). It's also a pain having to VACUUM a large table again just because a small number of rows need to be frozen. I'm not an expert at all, but I'd like to understand this, do you plan that READ-ONLY tables wouldn't even store transaction information? That should save quite a lot of space. Maybe when the table would be moved to the compressed tablespace, MVCC information could be dropped too? Of course that would avoid future insert update possibilities though. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Multiple SRF right after SELECT
A Dimecres 19 Març 2008, Nikolay Samokhvalov va escriure: 2. Why the query above provides 4 rows, not 2*4=8? Actually, that's interesting -- I can use this query to find l.c.m. But it's defenetely not that I'd expect before my try... 2*4 = 8: select * from generate_series(1, 2) a, generate_series(1, 4) b; Can't tell you about the expected behaviour in the query you provided though. -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] Images in PostgreSQL
A Dimarts 25 Març 2008, r[EMAIL PROTECTED] va escriure: Hi all, Does anybody know if is it possible to store images in Postgre? If it is possible which data type should I use? Yes it's possible, you can use BYTEA for this, for example. But please, this kind of questions should go to users mailing list. hackers is for people working on developing PostgreSQL itself. Thanks in advance, -- RD | Alea Management Technology Solutions -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] WIP: default values for function parameters
A Dissabte 13 Desembre 2008, Peter Eisentraut va escriure: On Friday 12 December 2008 20:05:57 Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed not break any existing features. Barring better ideas I think we should go with that one. I personally thought that AS was a better idea. +1 -- Albert Cervera i Areny http://www.NaN-tic.com -- 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] 16-bit page checksums for 9.2
A Dijous, 16 de febrer de 2012 12:16:31, Simon Riggs va escriure: v8 attached Maybe the docs should include what will happen if the checksum is not correct? -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog
Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol
A Dijous, 6 de setembre de 2012 00:30:53, Josh Berkus va escriure: In general I think the selling point for such a feature would be no administrative hassles, and I believe that has to go not only for the end-user experience but also for the application-developer experience. If you have to manage checkpointing and vacuuming in the application, you're probably soon going to look for another database. Well, don't discount the development/testing case. If you do agile or TDD (a lot of people do), you often have a workload which looks like: 1) Start framework 2) Start database 3) Load database with test data 4) Run tests 5) Print results 6) Shut down database In a case like that, you can live without checkpointing, even; the database is ephemeral. In other words, let's make this a feature and document it for use in testing, and that it's not really usable for production embedded apps yet. +1. Some projects such as tryton would benefit from this feature. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- 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] Enforce that INSERT...RETURNING preserves the order of multi rows
A Dimecres, 17 d'octubre de 2012 19:13:47, Merlin Moncure va escriure: On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan pe...@2ndquadrant.com wrote: On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote: Is that defined in the standard? RETURNING isn't even defined in the standard. Right: Point being, assumptions based on implementation ordering are generally to be avoided unless they are explicitly defined in the standard or elsewhere. I don't see how one could use RETURNING if result is not ensured to be in the same order as the tuples supplied. What's the use of RETURNING supplying data in random order? -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog
[HACKERS] developer.postgresql.org down
Maybe already known or in scheduled maintenance but developer.postgresql.org seems to be down right now. -- Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners Tel: +34 93 553 18 03 skype: nan-oficina http://twitter.com/albertnan http://www.nan-tic.com/blog
Re: [HACKERS] No Issue Tracker - Say it Ain't So!
2015-09-25 9:57 GMT+02:00 Torsten Zuehlsdorff <mailingli...@toco-domains.de>: > > > On 24.09.2015 20:23, David Fetter wrote: >> >> On Thu, Sep 24, 2015 at 12:10:07PM -0600, Ryan Pedela wrote: >>> >>> Kam Lasater wrote: >>>> >>>> I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in >>>> that order). There are tens to hundreds of other great ones out there, >>>> I'm sure one of them would also work. >>> >>> >>> Why not just use Github issues? >> >> >> Is Github issues something we can run ourselves? >> >> If not, it's a proprietary system which has a proprietor whose >> existence even next month is not guaranteed, and whose interests are >> not guaranteed to align with ours into an indefinite future. >> >> In some very important sense, it does not matter what features a >> system has if it isn't one we can control. At a minimum, this means >> we need to run it in its entirety on resources we control, and we need >> to be able to patch any piece of it on our own say-so. > > > + 1 > > Instead of Github maybe GitLab is a good choice. There is an open source > community edition you have the full control over. And it is used by more > than 100.000 organizations: > > https://en.wikipedia.org/wiki/GitLab > Of course everyone has their own preferences. Just wanted to point you to roundup [1]. It's: - Simple - Python - Very easy to extend - Integrates well with e-mail - Complete web interface We use it for the Tryton [2] project and the source code we use is available here [3] so you can take a look how easy it is to add new fields and other stuff. We use mercurial but commits automatically close the bug reports and we have links with the codereview. [1] http://roundup.sourceforge.net/docs/features.html [2] https://bugs.tryton.org [3] http://hg.tryton.org/bugs.tryton.org/ -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
