Le lundi 30 mars 2009 à 15:21:38, Sergey Burladyan a écrit :
Peter Eisentraut pete...@gmx.net writes:
I have now committed a more extensive pluralization, but your case is
included there.
As for the ru.po file, please see http://babel.postgresql.org/.
Great! I am translating 8.3
Simon Riggs a écrit :
On Fri, 2009-01-02 at 17:35 +, Simon Riggs wrote:
I use latest CVS version. I tried to apply the patches and I have the
following error :
Thanks, will fix.
Fixed various bit rots and re-packaged. v6a now up, v6 unlinked.
Thanks. I only did a few checks and it
Simon Riggs a écrit :
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link above), with these changes:
* Must ignore_killed_tuples and never
Bernd Helmle a écrit :
--On Donnerstag, November 06, 2008 11:35:54 +0100 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Guillaume Lelarge a écrit :
v4 patch attached.
v5 patch attached.
Thanks Guillaume.
Maybe this is nit-picking, but i see that you have to rmdir() an
existing empty
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
v5 patch attached.
Applied with corrections, mostly ensuring crash-safety and arranging
to clean up if the initial copy phase fails (think out-of-disk-space).
Thanks for your tips and corrections. I'll go read the diff
Tom Lane a écrit :
Bernd Helmle [EMAIL PROTECTED] writes:
* We really should error out when trying to copy into the same tablespace
the database already lives in.
No, I think that should just be a no-op. We don't for instance throw
error when you ALTER OWNER to the existing owner.
Guillaume Lelarge a écrit :
v4 patch attached.
v5 patch attached.
Fixes two issues :
* I forgot about Bernd's advice : And i think we can avoid to call
database_file_update_needed() in this case then. This is fixed.
* I forgot to remove a debug ereport.
Sorry about
Bernd Helmle a écrit :
--On Samstag, Oktober 25, 2008 23:50:47 +0200 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Here is my patch to add the ALTER DATABASE WITH TABLESPACE statement. It
is part of the TODO list. It intends to allow the move of all relations
of a database in its new default
Bernd Helmle a écrit :
--On Dienstag, November 04, 2008 14:56:44 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
[...]
Not sure what Bernd tried exactly, but it can be done.
Cool, i didn't recognize the obvious possibility to add a separate rule
for this. I've just extended the
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
Should I provide a complete new patch with Bernd's and Tom's changes?
Please --- it's better if you integrate it since you know the patch
already.
I worked with Bernd's patch and replace the WITH syntax with the SET
one
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
So, it seems to work. I say seems because there's no XLOG record that
says I moved all relations from one tablespace to another. Am I right in
thinking I need to insert a new XLOG record? should I create a new one?
You certainly
Hi,
Here is my patch to add the ALTER DATABASE WITH TABLESPACE statement. It
is part of the TODO list. It intends to allow the move of all relations
of a database in its new default tablespace.
Comments welcome.
Regards.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
To get the list of relations to move, the user needs to be connected to
the database.
Why? If what you are doing is changing the database's default
tablespace (which IMHO is what such a command ought to do)
That's exactly what
Hi,
I'm currently working on a patch for the TODO item :
Allow databases to be moved to different tablespaces
I already changed the syntax, added some code to move the relations of
the specific database to the target tablespace. It works. But I have
three issues I would like to discuss.
To
Heikki Linnakangas a écrit :
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yeah, seems like we need to allocate a new relfilenode in the new
tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also
Hi,
I just found a weird behaviour with this statement. Here is a complete
log of my session with a 8.3(.4) server:
[EMAIL PROTECTED] mkdir /home/guillaume/ts1
[EMAIL PROTECTED] createdb db1
[EMAIL PROTECTED] LANG=C psql db1
Welcome to psql 8.3.4, the PostgreSQL interactive terminal.
Type:
Tom Lane a écrit :
Heikki Linnakangas [EMAIL PROTECTED] writes:
The trivial fix is to just force a checkpoint in ALTER TABLE SET
TABLESPACE. Can we do better than that? Perhaps only force a checkpoint
when we find that the file already exists.
If ALTER TABLE SET TABLESPACE is assuming
Tom Lane a écrit :
I'm fooling around with Guillaume Lelarge's patch to make psql's \d
commands work with older server versions. The patch as submitted
works with servers back to 7.4 (modulo a small bug or two). I tried
to see what it'd take to make it work with 7.3. I count about a dozen
Bruce Momjian a écrit :
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get. I am in no way suggesting we do that for the FAQ.
What
Alvaro Herrera a écrit :
[...]
For those that think that the \du output is currently OK because it
doesn't wrap, consider the french translation which is quite a bit wider
than the original:
alvherre=# \du
Liste des rôles
Nom du rôle | Superutilisateur |
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I suggest
cannot execute \%s\ on \%s\ because ...
Hmm, why not just
cannot execute %s \%s\ because ...
?
Hmm, yeah, that seems fine too. Thinking more about it, from the POV of
the translator
Hi all,
I'm not sure psql handles \dFp the right way. The query allows
translators to translate some columns' values but forgets to escape the
strings. So, here is a patch that escapes these translated strings.
Regards.
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
Index:
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I'm not sure psql handles \dFp the right way. The query allows
translators to translate some columns' values but forgets to escape the
strings. So, here is a patch that escapes these translated strings.
This seems mighty ugly
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
Tom Lane a écrit :
This seems mighty ugly, and it's not the way we handle any other \d
command. Why is it needed for \dFp (and only that)?
The problem here is that Start parse is translated with Début de
l'analyse (which
Alvaro Herrera a écrit :
Guillaume Lelarge wrote:
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I try to answer a simple question : what happens when I do a simple
INSERT on a just started PostgreSQL server.
From what I understand with the INSERT statement, here is what
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I try to answer a simple question : what happens when I do a simple
INSERT on a just started PostgreSQL server.
From what I understand with the INSERT statement, here is what happens :
* backend loads first (and only) block
Hi,
First, I'm not sure this mail should go to this mailing list. As it
refers to source code (mainly src/backend/postmaster/bgwriter.c and
src/backend/access/transam/xlog.c), I sent it here. I apologize if I'm
wrong.
I'm a bit puzzled by the different informations I can read on the
Alvaro Herrera a écrit :
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but
we
have a couple of violations either way, which I'd like to fix, but what to?
79
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
I wonder why all messages going through errcontext function are not
translatable.
I don't think it's errcontext's fault. The PLs in general don't have
any translation coverage. This seems a bit difficult to fix: I don't
think
Hi,
I wonder why all messages going through errcontext function are not
translatable. I found this when working on PL/pgsql but it seems other
functions (like COPY, see backend/commands/copy.c) call errcontext and
none propose translatable messages.
Can I send a patch so we can translate them ?
Magnus Hagander a écrit :
On Thu, Sep 13, 2007 at 12:12:28AM +0200, Guillaume Lelarge wrote:
[...]
It seems pretty straightforward now. Perhaps it can be used with cron.
No. Doing that with cron is a really bad idea, imho. We do *not* want any
automated commits going into the tree. If we
Tom Lane a écrit :
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?
It certainly will show up if you do it before the packagers pull their
CVS copies.
No, it will
Dave Page a écrit :
Guillaume Lelarge wrote:
Tom Lane a écrit :
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Does this mean that if I commit something in these days to those
branches, it will not show up in the releases?
It certainly will show up if you do it before
Tom Lane a écrit :
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter usually does it --- in theory any committer could, but he actually
knows what to do and the rest of us would have to study ;-)
Study or figure it out? If it hasn't already been it should be
documented as part of
korry.douglas a écrit :
Now that we've announced (see
http://www.informationweek.com/news/showArticle.jhtml?articleID=201803375subSection=News)
that 8.3 will include a debugger (don't worry, it's a PL/pgSQL debugger
:-), has anyone actually tried it yet (other than myself and Dave Page)?
I
Andrew Dunstan a écrit :
Albert Cervera i Areny wrote:
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
Jim C. Nasby a écrit :
On Fri, Jul 13, 2007 at 01:45:18PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
According to http://developer.postgresql.org/index.php/Feature_Matrix,
8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
CREATE INDEX CONCURRENTLY
Well, I guess
Dave Page a écrit :
Hi Michael,
Looks like your latest commit fixed the problem. Thanks for working on it.
But it breaks 8.2 and 8.1 branches. See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=kitedt=2007-05-21%2007:47:01.
I've send a patch on pgsql-patch that fixes it.
Regards.
--
Bruce Momjian a écrit :
Standard English uses may, can, and might in different ways:
may - permission, You may borrow my rake.
can - ability, I can lift that log.
might - possibility, It might rain today.
Unfortunately, in conversational English, their
Peter Eisentraut a ecrit le 17/01/2007 10:16:
Am Mittwoch, 17. Januar 2007 08:54 schrieb Guillaume Lelarge:
It seems to me that the latest french .po files in pgtranslation are not
used in the 8.2.1 release and I wonder why.
Because those making the release failed to actually follow
Hi all,
It seems to me that the latest french .po files in pgtranslation are not
used in the 8.2.1 release and I wonder why. How do you synchronize
between the pgtranslation project tree and the PostgreSQL CVS source
tree ? and how often is it done ?
Thanks.
Regards.
--
Guillaume.
!--
Hi all,
I tried to work with NULL items in an array but there are two things I
don't understand. (I just did a cvs update, make, make install... so
sources are current.)
On http://momjian.us/main/writings/pgsql/sgml/arrays.html, you can read :
To set an element of an array constant to NULL,
Martijn van Oosterhout a écrit :
On Sun, Nov 05, 2006 at 08:23:59PM +0100, Guillaume Lelarge wrote:
Setting a NULL value seems to work.
amarok=# SELECT ARRAY['a',NULL,'c'];
ERROR: column NULL does not exist
LINE 1: SELECT ARRAY['a',NULL,'c'];
^
Using double
Le Samedi 10 Décembre 2005 17:43, vous avez écrit :
Guillaume LELARGE [EMAIL PROTECTED] writes:
Apparently, I can rename all schemas, even system schemas !
metier=# alter schema pg_catalog rename to foobar;
ALTER SCHEMA
If you are superuser, you can do anything you want, up
Le Mardi 13 Décembre 2005 00:13, Tom Lane a écrit :
Guillaume LELARGE [EMAIL PROTECTED] writes:
I've made more tests on schemas. I'm able to drop information_schema and
public schemas but I can't drop pg_catalog and pg_toast. It makes me
think that only pg_* are system schemas
Hi,
At my work, I have to dump a database and restore it on another database under
a specific schema. My first idea was to create the new schema on the old
database, move all the database objects on this new schema, dump the old db
and restore on the new one. But I have to move quite a lot of
Sorry for this late answer. I tried a lot of things and it still doesn't work.
2005/11/11, Martijn van Oosterhout kleptog@svana.org:
On Thu, Nov 10, 2005 at 11:53:04PM +0100, Guillaume LELARGE wrote:
Hi,
I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
seemed
Sorry for answering this late.
2005/11/16, Larry Rosenman ler@lerctr.org:
Bruce Momjian wrote:
The SCO compiler is so buggy (and for so many years) I see no reason
to even look at a bug report from someone using it.
I **REALLY** wish you would STOP saying that, Bruce. The current
2005/11/23, Joshua D. Drake [EMAIL PROTECTED]:
I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
Old SVR3 compiler.
We **REALLY** **SHOULD** look at it.
Well actually no, we
Hi,
I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
seemed to work well with psql and such tools. I tried to connect to
this server with pgAdmin3 and a query failed. I tried to find which
part of the query was wrong and I have a strange result :
SELECT 1 FROM pg_language
Le Lundi 19 Septembre 2005 07:38, Peter Eisentraut a écrit :
I think beta 2 is a good time to start fixing up the translations again.
Great :)
I think I'm gonna work on it soon because I'm nearly done with the translation
of the 8.1-beta2 manual.
As I had previously announced, long-time
101 - 151 of 151 matches
Mail list logo
