2010/1/12 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Hi, I'm reviewing OPEN FOR EXECUTE USING patch and have a couple of
trivial comments.
Pavel Stehule pavel.steh...@gmail.com wrote:
this small patch add missing USING clause to OPEN FOR EXECUTE statement
+ cleaning part of
Michael Meskes írta:
On Sun, Jan 10, 2010 at 07:16:59PM +0100, Boszormenyi Zoltan wrote:
As would ecpg_dynamic_type(), then. :-(
My guess is that this function is fine when returning InvalidOid = 0. AFAICT
it
is supposed to fill an integer with the SQL3 type code which seems to
Stefan Kaltenbrunner wrote:
so is there an actually concrete proposal of _what_ interals to expose? '
The pieces are coming together...summary:
-Status quo: really bad, but could probably ship anyway because
existing PITR is no better and people manage to use it
-Add slave
Thanks for your advice!
On Wed, Jan 13, 2010 at 3:37 AM, Magnus Hagander mag...@hagander.net wrote:
This change which moves walreceiver process into a dynamically loaded
module caused the following compile error on my MinGW environment.
That sounds strange - it should pick those up from the
Jaime Casanova írta:
2010/1/13 Boszormenyi Zoltan z...@cybertec.at:
Tom Lane írta:
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
What I did there is to check the return value of LockRelationOid()
the hunk was because a diference
I found following strange error on gothic moth:
== pgsql.22658/src/test/regress/regression.diffs
===
***
/zfs_data/home/postgres/buildfarm/gothic_moth/HEAD/pgsql.22658/src/test/regress/expected/vacuum.out
Tue Jan 12 22:06:13 2010
---
Fujii Masao wrote:
Done. Currently there is no new libpq function for replication. The
walreceiver uses only existing functions like PQconnectdb, PQexec,
PQgetCopyData, etc.
git://git.postgresql.org/git/users/fujii/postgres.git
branch: replication
Thanks!
I'm afraid we haven't quite
On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas robertmh...@gmail.com wrote:
I would strongly suggest to Tim that he rip the portions of this patch
that are related to this feature out and submit them separately so
that we can commit
Our documentation suggests that you can take a base backup of a warm
standby server while it's running:
If we take a backup of the standby server's data directory while it is
processing logs shipped from the primary, we will be able to reload that data
and restart the standby's recovery
On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Our documentation suggests that you can take a base backup of a warm
standby server while it's running:
If we take a backup of the standby server's data directory while it is
processing logs
Jaime Casanova írta:
2010/1/13 Boszormenyi Zoltan z...@cybertec.at:
Tom Lane írta:
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
What I did there is to check the return value of LockRelationOid()
the hunk was because a diference
Fujii Masao wrote:
On Wed, Jan 13, 2010 at 8:36 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I wonder if it would be enough to document that pg_control must be
backed up first?
Probably No. The archive recovery from such base backup would always
fail at the end of
/end is used since it was introduced.
Comments?
Regards,
--
Hitoshi Harada
more_frame_options.20100113.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
Hans,
nce Jaime already asked for a use case, just a few small comments from
me.
@@ -4,6 +4,7 @@
#include postgres_fe.h
#include ctype.h
+#include inttypes.h
This is not portable. You don't want to include this header.
Did I see this right that you use the statement cache for
On Wed, Jan 13, 2010 at 09:22:28AM +0100, Boszormenyi Zoltan wrote:
I think it's best to assume a string. ecpg_set_{compat,native}_sqlda()
uses the defailt case in that meaning anyway.
Okay, applied as you send it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
On Sun, 2010-01-03 at 11:55 +0100, Martijn van Oosterhout wrote:
On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
The JDBC driver does want cancel if active behavior. The JDBC API
specifies Statement.cancel() where Statement is running one particular
backend query. So it
README.bloom:
contrib/bloom provides signature file based index.
Authors: Teodor Sigaev (teo...@sigaev.ru) and Oleg Bartunov (o...@sai.msu.su)
Notes: This is a *working* prototype, which can be finishing up to production
in case of interest. Particularly, it misses wal support, because of
2010/1/13 Boszormenyi Zoltan z...@cybertec.at:
well, i actually think that PANIC is too high for this...
Well, it tries to lock and then open a critical system index.
Failure to open it has PANIC, it seemed appropriate to use
the same error level if the lock failure case.
if you try to
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
What I did there is to check the return value of LockRelationOid()
and also elog(PANIC) if the lock wasn't available.
Does it need rethinking?
Yes.
2010/1/13 Teodor Sigaev teo...@sigaev.ru:
CREATE INDEX bloomidx ON tbloom(i1,i2,i3)
WITH (length=5, col1=2, col2=2, col3=4);
Here, we create bloom index with signature length 80 bits and attributes
i1, i2 mapped to 2 bits, attribute i3 - to 4 bits.
This is pretty darn slick. I
This is pretty darn slick. I haven't looked at the code yet, but the
It's just a prototype and/or proof of concept
functionality sounds very cool, and I hope this is something we'll be
able to have as part of PG in the future (though more than likely not
for 8.5, I suspect).
Of course
--
(4) In conclusion, I hope that PostgreSQL will keep xml2
or something similar even when the XSLT and speculative parsing
issues have been addressed.
Given your interest in XML2, would you like to be come a maintainer of
the module?
--Josh Berkus
--
Sent via pgsql-hackers mailing list
On Tue, 2010-01-12 at 20:06 -0800, Josh Berkus wrote:
So it seems to me that the threshold question for this patch is - do
we think it's a good idea to maintain two implementations of PL/python
in core?
Not really, no. This is why we need PGAN ;-)
If the new implementation is *better*
On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
I think it is important to remember that the current version of
PL/python is pretty weak compared to its counter parts (Specifically
PL/Perl).
How so?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, 2010-01-07 at 18:34 +0900, Fujii Masao wrote:
On Thu, Jan 7, 2010 at 6:09 PM, Joshua Tolley eggyk...@gmail.com wrote:
Having concluded I really need to start playing with hot standby, I started
looking for documentation on the subject. I found what I was looking for; I
also found
On Wed, 2010-01-13 at 19:53 +0200, Peter Eisentraut wrote:
On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
I think it is important to remember that the current version of
PL/python is pretty weak compared to its counter parts (Specifically
PL/Perl).
How so?
O.k. you may have
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
If there is, I am still all for it, but I am a python bigot.
Yeah, it's just my viewpoint that we don't want 2 python
I wrote:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
-- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
postgres
Um, that tag is the name, and if you change that, the name in CREATE
FUNCTION also changes.
So?
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan
We've been chewing around query cancel on Hot Standby and I think things
have got fairly confusing, hence a new thread.
I enclose a patch that includes all the things that we all agree on so
far, in my understanding
* Recovery conflict processing uses SIGUSR1 rather than shmem per Tom,
while
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
I agree. Why are arbitrary restrictions being placed on code
improvements? If code has no purpose, why not remove it, or at least
mark it as NOT_USED.
So, where do we go from
Robert Haas robertmh...@gmail.com wrote:
So, where do we go from here? Any other opinions?
It seems that we often have people cleaning up redundant or
unreachable code to improve code clarity. I'm not in a position
right now to confirm that this code is redundant, but if that has
been
Hello all,
I am a student-magister and I'm writting my magister work. I realized gist
index TPR tree - it is like a simple R tree but moving :)
Everything is compiling ok, I creating table and index, but after whese code
- DB is restarting :(((
*
*
*set enable_seqscan = false
select * from
On Wed, Jan 13, 2010 at 1:15 PM, Robert Haas robertmh...@gmail.com wrote:
So, where do we go from here? Any other opinions?
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we
I want to add than I have a piece of my code that looks very strange
Datum gist_mov_penalty(PG_FUNCTION_ARGS)
{
GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
float * result = (float *) PG_GETARG_POINTER(2);
*
Hi Simon,
On Wednesday 13 January 2010 19:24:22 Simon Riggs wrote:
We've been chewing around query cancel on Hot Standby and I think things
have got fairly confusing, hence a new thread.
Good idea.
I enclose a patch that includes all the things that we all agree on so
far, in my
January 13, 2010
PostgreSQL Conference East, The PostgreSQL Conference for Decision
Makers, End Users and Developers, is being held at the Radisson Plaza,
Warwick Hotel in Philadelphia on March 25th through 28th.
This is the second call for papers for this conference. You can review
the skeletal
Sergej,
I can not understand why DB is restarting ? It is restarting when SQL
begins use index :(((
Can anybody help me , I would by appretiate every people who downloads
my sources, try to deploy index and maybe solve where is the problem.
It would help if you gave people a link.
Also, if
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
What I did there is to check the return value of LockRelationOid()
and also elog(PANIC) if the lock wasn't
On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus j...@agliodbs.com wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
If there is, I am still all for it, but I am a python
On Wed, Jan 13, 2010 at 1:42 PM, Sergej Galkin sergej.gal...@gmail.com wrote:
I can not understand why DB is restarting ? It is restarting when SQL begins
use index :(((
Can anybody help me , I would by appretiate every people who downloads my
sources, try to deploy index and maybe solve where
On Wed, 2010-01-13 at 19:58 +0100, Andres Freund wrote:
I am still testing patch, so should be confident to commit tomorrow
barring issues.
I have only looked at briefly because right now I dont have the time (going
to
eat at a friends place...) but I think I spotted an issue:
The
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
plan is?
The chances of getting concensus on an
Zdenek Kotala zdenek.kot...@sun.com writes:
I found following strange error on gothic moth:
VACUUM FULL pg_class;
+ ERROR: deadlock detected
+ DETAIL: Process 5913 waits for AccessExclusiveLock on relation 2662
of database 16384; blocked by process 5915.
+ Process 5915 waits for
I debugged index with gdb and found that it is segmentation fault in my
procedure named *gist_mov_consistent* it is only 7 lines. So I think it is
worth to publish it to public,
*
* *Datum gist_mov_consistent(PG_FUNCTION_ARGS)*
*{*
*GISTENTRY *entry = (GISTENTRY *)PG_GETARG_POINTER(0);*
*
This is the first of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added utility functions: quote_literal, quote_nullable, quote_ident,
encode_bytea, decode_bytea, looks_like_number,
encode_array_literal, encode_array_constructor.
-
And
*int obj_contains(moving_object *a, BOX *b)
{
if (b-low.x a-x_low)
return 0;
if (b-low.y a-y_low)
return 0;
if (b-high.x a-x_high)
return 0;
if (b-high.y a-y_high)
return 0;
return 1;
}*
this is the procedure obj contains
On Wed, Jan
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
I agree. Why are arbitrary restrictions being placed on code
improvements? If code has no purpose, why not
I am realizing gist index and get a bug, that crashes DB. I' debugged my
program as Robert(thanks !) advised me and I know which procedure crashed.
*Datum gist_mov_consistent(PG_FUNCTION_ARGS)*
*{*
*GISTENTRY *entry = (GISTENTRY *)PG_GETARG_POINTER(0);*
*BOX *query = PG_GETARG_BOX_P(1);*
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine with it,
but that's not clear either. The argument for
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
Doing so, succinctly, is unfortunately difficult.
It is primarily a
On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
Doing
On Wed, 13 Jan 2010, Robert Haas wrote:
2010/1/13 Teodor Sigaev teo...@sigaev.ru:
CREATE INDEX bloomidx ON tbloom(i1,i2,i3)
WITH (length=5, col1=2, col2=2, col3=4);
Here, we create bloom index with signature length 80 bits and attributes
i1, i2 mapped to 2 bits, attribute i3 - to 4
robertmh...@gmail.com (Robert Haas) writes:
On Fri, Jan 8, 2010 at 10:12 AM, Dave Page dp...@pgadmin.org wrote:
I have long spoken against making Windows a second class citizen. But I
don't think David is going to do that (and I'll hound him if he does). But
that doesn't mean it has to be
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking permissions. Still, that's just
extending a window
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like most solutions would put us back to exactly what
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking
On ons, 2010-01-13 at 12:12 -0800, Joshua D. Drake wrote:
On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
Function Modules:
- Does away with the need for GD/SD (more natural Python environment).
- Allows tracebacks (tracebacks are useful, right?) to implemented easily.
-
Boszormenyi Zoltan írta:
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
What I did there is to check the return value of
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like
Alex Hunsaker bada...@gmail.com writes:
Im of the opinion if we are going to be meddling with the permission
checks in this area one of the goals should be close or at least
tighten up that window. So you cant lock a table you dont have
permission to (either via LOCK or ALTER TABLE).
Michael Meskes wrote:
Hans,
nce Jaime already asked for a use case, just a few small comments from
me.
@@ -4,6 +4,7 @@
#include postgres_fe.h
#include ctype.h
+#include inttypes.h
This is not portable. You don't want to include this header.
Did I see this right that you use the
On Wed, 2010-01-13 at 23:27 +0200, Peter Eisentraut wrote:
The problem I'm having with this discussion is that every time someone
asks what the supposed advantages of this new Python PL are, a feature
list like the above is dumped, 75% of which is subjective and tends to
use semi-buzzwords,
When you look at a table definition with psql \d, one of the arguably
most important pieces of information -- the primary key -- is hidden
somewhere below under indexes:
Table public.test2
Column | Type | Modifiers
+-+---
a | integer | not null
b |
Hans-Juergen Schoenig h...@cybertec.at writes:
Michael Meskes wrote:
Before looking into it in detail I think we should first figure out if this
feature really has a benefit.
the use cases for this thing are quite simple: we are currently porting
hundreds (!) of complex Informix terminal
On ons, 2010-01-13 at 13:33 -0800, Joshua D. Drake wrote:
The only thing I am currently looking for is an objective review of the
patch based on the benefits it provides.
Right, but I was opining that such a vague feature listing is not
adequate for that.
I can tell you that if the Pye
patch
Peter Eisentraut pete...@gmx.net writes:
I think we could easily improve that by having it look something like
this instead:
Table public.test2
Column | Type | Modifiers
+-+---
a | integer | PK
b | integer | PK
Indexes:
test2_pkey PRIMARY
I was surprised/annoyed to find out that there is no way to have
per-user pg_service.conf, something like ~/.pg_service.conf (well,
except by export PGSYSCONFDIR). That would be easy to add. Comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Robert Haas robertmh...@gmail.com wrote:
Nope, you're on target. Although - if I were you - I would post
the ACCESS EXCLUSIVE lock version of the patch for feedback. I
can't speak for anyone else, but I'll read it.
Here you go! :-)
This is the milestone of having full serializable
On Wed, Jan 13, 2010 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I think we could easily improve that by having it look something like
this instead:
Table public.test2
Column | Type | Modifiers
+-+---
a |
On Wed, Jan 13, 2010 at 4:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hans-Juergen Schoenig h...@cybertec.at writes:
Michael Meskes wrote:
Before looking into it in detail I think we should first figure out if this
feature really has a benefit.
the use cases for this thing are quite simple: we
On Wed, Jan 13, 2010 at 9:34 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
No, that's not an issue. We only wait for the backup-end record if we
haven't seen yet since we started recovery from the base backup.
Assuming the standby had reached that point already before the
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Here you go! :-)
Hmmm... I just got a write skew example to show a snapshot
isolation anomaly, so I've got something wrong still. :-(
Will continue to work on it. Sorry.
-Kevin
--
Sent via pgsql-hackers mailing list
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
This is the milestone of having full serializable behavior, albeit
with horrible performance, using the simplest implementation
possible.
A tad too simple, as it turns out. It did it's main job of
providing a simple milestone to identify
Peter Eisentraut pete...@gmx.net writes:
I was surprised/annoyed to find out that there is no way to have
per-user pg_service.conf, something like ~/.pg_service.conf (well,
except by export PGSYSCONFDIR). That would be easy to add. Comments?
+1.
I'll use it the day it exists.
--
dim
--
On Wed, Jan 13, 2010 at 11:49:59PM +0200, Peter Eisentraut wrote:
I was surprised/annoyed to find out that there is no way to have
per-user pg_service.conf, something like ~/.pg_service.conf (well,
except by export PGSYSCONFDIR). That would be easy to add. Comments?
+1 from me. I was
Patch authors, please make sure your patches are listed on
commitfest.postgresql.org.
https://commitfest.postgresql.org/action/commitfest_view/open
All, we still need reviewers for the following patches.
New XLOG record indicating WAL-skipping
Fix large object support in pg_dump
knngist (WIP)
Pavel Stehule pavel.steh...@gmail.com wrote:
ok, I accept all comments.
revised version are attached.
Good. This patch is ready to commit. I'll do it soon if no objections.
BTW, I found inconsistent parameter dumps in the codes. Some of them
add '$', but others does not. Are they
(2010/01/14 4:54), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine with it,
but that's
(2010/01/14 4:27), Stephen Frost wrote:
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
plan is?
I noticed odd stuff showing up when I fired up an 8.3 psql after using psql in
HEAD. It shows up in .psql_history as well:
deci...@platter.1[20:32]~:5%tail -n 2 .psql_history
\134df+\040tools.raise_exception
\df+ tools.raise_exception
deci...@platter.1[20:35]~:6%
(last entry is from the 8.3
Hi,
We support several methods for logging server messages. The native methods
(stderr, csvlogs) has poor management. We can't compress logs, send them to
another location/server, or just remove old ones. Another problem is that we
can't remove (automatically) old logs based on the number of
Jim Nasby deci...@decibel.org writes:
I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
in HEAD. It shows up in .psql_history as well:
Platform? readline version?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Euler Taveira de Oliveira eu...@timbira.com writes:
I want to propose a new command to be execute after the log file is
rotated.
(1) Windows compatibility?
(2) What happens if the command takes a significant amount of time to
execute? We can't afford to have the log collector blocked.
(3)
The similar matter can be reproduced with ALTER TABLE ... TYPE statement,
not only RENAME TO option.
postgres=# CREATE TABLE t1 (a int);
CREATE TABLE
postgres=# CREATE TABLE s1 (a int);
CREATE TABLE
postgres=# CREATE TABLE ts (b int) inherits (t1, s1);
NOTICE: merging multiple
Euler Taveira de Oliveira eu...@timbira.com wrote:
other log management softwares have a way to do that so why our logger doesn't
have such capability?
I want to propose a new command to be execute after the log file is rotated. A
GUC parameter log_after_rotation_command that takes a (set
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
The attached patch eliminates unneeded parentheses by using
pg_get_triggerdef(pretty = true) in psql.
Is this patch reversed? It seems so but the listed file timestamps
don't match that idea ...
regards, tom lane
On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
The problem I'm having with this discussion is that every time someone
asks what the supposed advantages of this new Python PL are, a feature
list like the above is dumped,
I agree that this is unfortunate, but how else can we to discuss the
On Jan 13, 2010, at 12:15 PM, Robert Haas wrote:
1. It's not just a rewrite, it's an incompatible rewrite that will
present significant user-visible behavioral differences. So replacing
the current implementation wholesale would produce massive breakage
for anyone actually using PL/python in
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
The attached patch eliminates unneeded parentheses by using
pg_get_triggerdef(pretty = true) in psql.
Is this patch reversed? It seems so but the listed file timestamps
don't match that idea ...
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Is this patch reversed? It seems so but the listed file timestamps
don't match that idea ...
Sorry, I cannot understand what you mean...
The patch looks like it removes, rather than adds, your
KaiGai Kohei wrote:
(2010/01/14 4:54), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine
The attached patch fixes bugs when we try to rename (and change type) on
a column inherited from the different origin and merged.
This patch adds:
List *find_column_origin(Oid relOid, const char *colName)
It returns the list of relation OIDs which originally defines the given
column. In most
James William Pye wrote:
On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
The problem I'm having with this discussion is that every time someone
asks what the supposed advantages of this new Python PL are, a feature
list like the above is dumped,
I agree that this is unfortunate,
2010/1/14 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Pavel Stehule pavel.steh...@gmail.com wrote:
ok, I accept all comments.
revised version are attached.
Good. This patch is ready to commit. I'll do it soon if no objections.
BTW, I found inconsistent parameter dumps in the codes.
Hi,
3) A nice set of SQL queries to return message, parts, threads,
folders based on $criteria (search, id, folder, etc)
I guess Matteo's working on that…
Right, but this is where I want to see the AOX schema imporove... In
ways like adding persistant tables for threading, which are
96 matches
Mail list logo
