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
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
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,
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
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,
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
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'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
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
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
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 :
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 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
Hi,
pg_restore --help gives this message for the --no-tablespaces parameter:
--no-tablespaces do not dump tablespace assignments
The message should say restore and not dump. You'll find a patch attached
that fixes this issue.
Thanks.
Regards.
--
Guillaume.
Le jeudi 19 novembre 2009 à 23:05:16, Peter Eisentraut a écrit :
On tor, 2009-11-19 at 16:47 +0100, Guillaume Lelarge wrote:
pg_restore --help gives this message for the --no-tablespaces
parameter:
--no-tablespaces do not dump tablespace assignments
The message should say
Le mardi 15 décembre 2009 à 06:30:15, Greg Smith a écrit :
[...]
BTW, this list is listed as the list for tech questions in the pgAdmin
tips, therefore if you don't want to be disturb, you might want to
remove it from the pgAdmin tips.
When I look at http://www.pgadmin.org/support/ for
Le 18/12/2009 18:07, Tom Lane a écrit :
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
$ time initdb
... blah blah blah ...
real0m17.953s
user0m6.490s
sys 0m10.935s
$ rm
Le 13/11/2009 12:11, Dave Page a écrit :
[...]
What about pg_dump/psql setting fallback_application_name?
Per Tom, I'm waiting on the possible new array-based libpq connect API
which will make a conversion of those utilities from PQsetdbLogin a
lot cleaner than moving to PQconnectdb (and
Le 28/12/2009 10:07, Dave Page a écrit :
On Sun, Dec 27, 2009 at 11:15 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 13/11/2009 12:11, Dave Page a écrit :
[...]
What about pg_dump/psql setting fallback_application_name?
Per Tom, I'm waiting on the possible new array-based libpq
Le 28/12/2009 17:06, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 10:07, Dave Page a écrit :
Yes, still waiting on the new API.
Is there something I can do to make this move forward?
I think we were stalled on the question of whether to use one array
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were stalled on the question of whether to use one array
or two parallel arrays. Do you want to try coding up a sample usage
of each possibility so we
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were stalled on the question of whether to use one array
or two parallel arrays. Do you want to try
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were stalled on the question of whether to use one
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were
Le 07/01/2010 19:13, Robert Haas a écrit :
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59
Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
Le 07/01/2010 19:13, Robert Haas a écrit :
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03
Le 15/01/2010 18:53, Guillaume Lelarge a écrit :
Le 08/01/2010 23:22, Guillaume Lelarge a écrit :
Le 07/01/2010 19:13, Robert Haas a écrit :
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12
Le 24/01/2010 06:06, Jaime Casanova a écrit :
On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas robertmh...@gmail.com wrote:
I was also thinking about the possibility of adding a new option
called output and making that control whether the Output line gets
printed. It's kind of annoying to use
Le 26/01/2010 00:04, Joe Conway a écrit :
I'm reviewing the patch posted here:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
for this commitfest item:
https://commitfest.postgresql.org/action/patch_view?id=259
First, thanks for reviewing my patch.
Patch attached -
Le 26/01/2010 19:43, Joe Conway a écrit :
On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the manual.
Please send the documentation as a separate patch. Once I have that I
will commit
Le 28/01/2010 07:32, Joe Conway a écrit :
On 01/26/2010 02:55 PM, Guillaume Lelarge wrote:
Le 26/01/2010 19:43, Joe Conway a écrit :
On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the manual
Hi,
I worked on a patch to make PostgreSQL binaries use the new
PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway
changed my previous patch.
I know I'm way over the deadline for this commitfest. I couldn't do it
before because my previous patch (on this commit fest)
Le 31/01/2010 13:39, Magnus Hagander a écrit :
On Sun, Jan 31, 2010 at 09:34, Guillaume Lelarge guilla...@lelarge.info
wrote:
Hi,
I worked on a patch to make PostgreSQL binaries use the new
PQconnectdbParams() libpq functions. I tried to mimic the way Joe Conway
changed my previous patch
Le 31/01/2010 17:35, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
*/
do
{
+ const char *values[] = {
+ my_opts-hostname,
+ my_opts-port,
+ my_opts-dbname,
+ my_opts
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.
--
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
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
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
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
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
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 ?
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
Le mercredi 28 octobre 2009 à 15:11:31, Anders Steinlein a écrit :
Is there any interest in expanding \dn+ to show schema size, similar
to table sizes using \dt+ in 8.4? We use separate schemas for each
user, so this would allow us to quickly look up the sizes of each
user's data.
I have
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
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
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
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
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
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
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 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
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 |
Hi,
Today, I tried to cancel the change of a tablespace for a table (ALTER
TABLE ... SET TABLESPACE). I got the Cancel request sent but the query
continued and finally succeed. It was a big issue for my customer, and I
wanted to look more into that issue. So, I got a look at the source code
and
Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
[...]
Tom Lane t...@sss.pgh.pa.us wrote:
I'm of the opinion that this is a 9.1 problem. It needs more thought
than we can put into it now --- one obvious question is what about
monitoring on the slave side? Another is who should be able to
Le 22/06/2010 12:42, Simon Riggs a écrit :
On Tue, 2010-06-22 at 12:19 +0200, Guillaume Lelarge wrote:
Shamely simple : I only added some informations on the server's
properties. See
http://www.pgadmin.org/images/visualtour12/visualtour08.jpg. We only
display the fact that the server
Le 22/06/2010 11:41, Simon Riggs a écrit :
On Tue, 2010-06-22 at 09:54 +0200, Guillaume Lelarge wrote:
I added support for Hot Standby /
Streaming Replication in pgAdmin (that was a really small patch, there
was not a lot to do)
Well done.
Does this mean that pgAdmin has a read only mode
Le 23/06/2010 22:54, Tom Lane a écrit :
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
copy_dir(), and copy_file() functions. Works for me on ALTER
Le 23/06/2010 23:29, Guillaume Lelarge a écrit :
Le 23/06/2010 22:54, Tom Lane a écrit :
Robert Haas robertmh...@gmail.com writes:
On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
copy_dir
Le 30/06/2010 05:25, Tom Lane a écrit :
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see the patch on the commit-fest page yet.
I tend to think
Le 30/06/2010 06:53, Guillaume Lelarge a écrit :
Le 30/06/2010 05:25, Tom Lane a écrit :
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something we want fixed for 9.0, as indicated by Simon?
I don't see
Le 01/07/2010 17:54, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
On Tue, Jun 29, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote:
So this is not something
Le 01/07/2010 22:13, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 12:11 PM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 01/07/2010 17:54, Robert Haas a écrit :
On Thu, Jul 1, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 1, 2010 at 5:30 AM, Guillaume Lelarge
Le 15/07/2010 17:48, Joshua D. Drake a écrit :
On Thu, 2010-07-15 at 16:20 +0100, Simon Riggs wrote:
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The biggest turn off that most people experience when using PostgreSQL
is that psql does not
Le 21/07/2010 23:23, Andreas Joseph Krogh a écrit :
[...]
I was googling for how to create a text-seach-config with the following
properties:
- Map unicode accentuated letters to an un-accentuated equivalent
- No stop-words
- Lowercase all words
And came over this from -general:
Le 21/07/2010 09:53, Dave Page a écrit :
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut pete...@gmx.net wrote:
My preference would be to stick to a style where we identify the
committer using the author tag and note the patch author, reviewers,
whether the committer made changes, etc. in
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
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
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
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
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.
!--
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
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
On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
Basically I like this whole idea, but I'd like to know why do you think
this functionality is required?
How should a synchronous master handle
Hi,
On a french PostgreSQL web forum, one of our users asked about a curious
behaviour of the intarray extension.
This query:
SELECT ARRAY[-1,3,1] ARRAY[1, 2];
should give {1} as a result.
But, on HEAD (and according to his tests, on 9.0.6 and 9.1.2), it
appears to give en empty array.
On Thu, 2012-02-16 at 19:27 -0500, Tom Lane wrote:
Guillaume Lelarge guilla...@lelarge.info writes:
This query:
SELECT ARRAY[-1,3,1] ARRAY[1, 2];
should give {1} as a result.
But, on HEAD (and according to his tests, on 9.0.6 and 9.1.2), it
appears to give en empty array
Le 28/12/2010 16:34, Tom Lane a écrit :
Magnus Hagander mag...@hagander.net writes:
On Dec 28, 2010 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What's the use case? And aren't there security reasons to NOT expose
that? It might contain a password for instance.
Good point - should be made
Le 28/12/2010 17:36, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2010 16:34, Tom Lane a écrit :
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files
Le 28/12/2010 17:50, Gurjeet Singh a écrit :
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I can see the point of, say, a primary_host_address() function returning
inet, which would be way better on both those dimensions than the
current proposal. But I'm not sure
Le 28/12/2010 18:12, Robert Haas a écrit :
On Dec 28, 2010, at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config files, no?
SQL access is
Le 28/12/2010 19:30, Tom Lane a écrit :
Gurjeet Singh singh.gurj...@gmail.com writes:
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com wrote:
SQL access is frequently more convenient, though. Although maybe now that
we've made recovery.conf use the GUC lexer we oughta
Le 01/01/2011 06:05, Robert Haas a écrit :
On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
No, quite the opposite. With the other approach, you needed:
constraints cannot be used on views
constraints cannot be
Le 01/01/2011 16:00, Robert Haas a écrit :
On Sat, Jan 1, 2011 at 9:53 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 01/01/2011 06:05, Robert Haas a écrit :
On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote
Hi,
Today, I tried to make fun with the new background worker processes in
9.3, but I found something disturbing, and need help to go further.
My code is available on https://github.com/gleu/stats_recorder. If you
take a look, it is basically a copy of Alvarro's worker_spi contrib
module with a
On Mon, 2012-12-31 at 11:03 -0300, Alvaro Herrera wrote:
Guillaume Lelarge wrote:
Hi,
Today, I tried to make fun with the new background worker processes in
9.3, but I found something disturbing, and need help to go further.
Thanks.
Is it the work of the function (pointed
On Mon, 2012-12-31 at 12:54 -0300, Alvaro Herrera wrote:
Guillaume Lelarge wrote:
On Mon, 2012-12-31 at 11:03 -0300, Alvaro Herrera wrote:
I think this (have a config option, and have SIGHUP work as expected)
would be useful to demo in worker_spi, if you care to submit a patch
On Mon, 2012-12-31 at 17:44 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Guillaume Lelarge wrote:
On Mon, 2012-12-31 at 11:03 -0300, Alvaro Herrera wrote:
I think this (have a config option, and have SIGHUP work as expected)
would be useful to demo in worker_spi, if you care
1 - 100 of 151 matches
Mail list logo
