On Mon, 2009-10-26 at 10:12 -0700, Greg Stark wrote:
While i agree this looks nicer I wonder what it does to things like
excel/gnumeric/ooffice auto-recognizing table layouts and importing
files. I'm not sure our old format was so great for this so maybe this
is actually an improvement I'm
On Mon, 2009-10-26 at 14:13 -0700, Greg Stark wrote:
On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus j...@agliodbs.com wrote:
Different issue, really, which is that some people (including me) would
like to break up PostgreSQL configuration into 7 or 8 files based on
functional area (e.g.
Hi, thank you for your response.
But does this mean, that only WinXP is no supported or doesn't it work at all?
I would need it on a Windows2003Server???
Best regards,
murphy
-Ursprüngliche Nachricht-
Von: Fujii Masao [mailto:masao.fu...@gmail.com]
Gesendet: Montag, 26. Oktober 2009
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
It sounds like there's a consensus brewing here on what should get done
with this particular patch now. Let me try to summarize:
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list
Hi,
Greg Smith gsm...@gregsmith.com writes:
It sounds like there's a consensus brewing here on what should get done with
this particular patch now. Let me try to summarize:
-The new feature should be activated by allowing you to specify a directory
to include in the postgresql.conf like
dp...@pgadmin.org (Dave Page) writes:
As Tom says though, the effect this has on users is zero. The licence
is still the same as its always been, regardless of what we say it is
based on or looks like.
There may be a fairly miniscule one...
There do exist GPL zealots that bash, as not free
On Mon, Oct 26, 2009 at 7:02 PM, Chris Browne cbbro...@acm.org wrote:
dp...@pgadmin.org (Dave Page) writes:
As Tom says though, the effect this has on users is zero. The licence
is still the same as its always been, regardless of what we say it is
based on or looks like.
There may be a
On Mon, Oct 26, 2009 at 11:33:40PM +, Roger Leigh wrote:
On Mon, Oct 26, 2009 at 07:19:24PM -0400, Tom Lane wrote:
Roger Leigh rle...@codelibre.net writes:
On Mon, Oct 26, 2009 at 01:33:19PM -0400, Tom Lane wrote:
Yeah. We can do what we like with the UTF8 format but I'm considerably
On Mon, Oct 26, 2009 at 11:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Kiswono Prayogo wrote:
plv8js is a procedural language add-on for PostgreSQL, which means you
can define Javascript functions that run inside a PostgreSQL server
using google V8 Engine.
anyone who want to contribute
Merlin Moncure wrote:
On Mon, Oct 26, 2009 at 11:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Kiswono Prayogo wrote:
plv8js is a procedural language add-on for PostgreSQL, which means you
can define Javascript functions that run inside a PostgreSQL server
using google V8 Engine.
On Tue, Oct 27, 2009 at 08:30:16AM -0400, Andrew Dunstan wrote:
If someone is going to work on a JS engine for PostgreSQL (which I think
is a good idea, actually) I want them to work on one that is likely to
succeed.
The project (at the moment) just seems to be a set of pointers to code
I
On Mon, Oct 26, 2009 at 06:35:13PM -0700, Christophe Pettus wrote:
On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote:
Hmmm, hashtext() returns int32. ,
Can you reduce the collision issue if we had hashtext64()?
That would certainly reduce the chance of a collison considerably, assuming
On Mon, Oct 26, 2009 at 4:30 PM, Josh Berkus j...@agliodbs.com wrote:
Why aren't you satisfied with hashtext('foo') ?
Collisions, mostly.
Why even bother with a hash function when you can just have multiple
table pull from a shared sequence? AFAICT, this solves the OP's
problem with no
Itagaki Takahiro wrote:
Jeff Davis pg...@j-davis.com wrote:
http://www.postgresql.org/docs/8.4/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
Looking at that page briefly I would assume that it could be set.
Oops, I forgot to fix the description when I disable
Hi, hackers
I have a problem at PostgreSQL 8.3.5 (Slackware Server and Win 2003 Server)
SO independent.
When run the scripts below I receive the error:
---
testes=# DELETE FROM pai WHERE co_pai = 1;
server closed the
Marcelo Costa escreveu:
Hi, hackers
I have a problem at PostgreSQL 8.3.5 (Slackware Server and Win 2003
Server) SO independent.
When run the scripts below I receive the error:
This is not a bug. There are many ways to shoot yourself in the foot; and it
is one of them...
UPDATE
In yesterday's discussions about FOR UPDATE there was some mention of
making it not propagate into WITH subqueries:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01540.php
That is, given
WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE
should foo be locked FOR UPDATE
Alvaro Herrera escreveu:
Tom Lane escribió:
Greg Stark gsst...@mit.edu writes:
Still far from convinced on that one. But effective_io_concurrency
should be included even in the first pass.
I think a design that is limited to a prespecified set of GUCs is
broken by definition. It'd be better
I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic changes.
... although on reflection, I'm not sure *why* we push FOR
On Mon, 2009-10-26 at 17:23 +, Dean Rasheed wrote:
If it's of any relevance, I'm currently using an optimised build, with
assert checking off.
[Linux x86_64, 2 core Intel Core2]
Ok, I'm able to reproduce it now. Thanks for looking into it!
Regards,
Jeff Davis
--
Sent via
Hackers,
There are some GUCs you can set in a context which will accept them, yet
they have no effect when you do. For example, I can call SET
statement_timeout inside a function, and it has no effect whatsoever.
I'm wondering if we should be throwing a warning in these cases. And
how many
Merlin,
Why even bother with a hash function when you can just have multiple
table pull from a shared sequence? AFAICT, this solves the OP's
problem with no downsides (I used the approach with excellent results
in a ported cobol app which had pessimistic locking requirement).
Well, if you
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
Could the desired behavior be obtained using a CTE?
Nope, we push FOR UPDATE into WITHs too. I don't really see any way to
deal with this without some sort of semantic
On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Marcelo Costa escreveu:
Hi, hackers
I have a problem at PostgreSQL 8.3.5 (Slackware Server and Win 2003
Server) SO independent.
When run the scripts below I receive the error:
This is not a bug. There are
On 10/27/09 9:36 AM, Josh Berkus wrote:
Hackers,
There are some GUCs you can set in a context which will accept them, yet
they have no effect when you do. For example, I can call SET
statement_timeout inside a function, and it has no effect whatsoever.
I'm wondering if we should be
On Tue, Oct 27, 2009 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In yesterday's discussions about FOR UPDATE there was some mention of
making it not propagate into WITH subqueries:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01540.php
That is, given
WITH w AS (SELECT * FROM
Greg Smith gsm...@gregsmith.com wrote:
On Mon, 26 Oct 2009, Kevin Grittner wrote:
for our 72 production servers for county Circuit Court systems, we
copy an identical postgresql.conf file to each county, with the
last line being an include to an overrides conf file in /etc/.
For most
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I am thinking we should do is define that FOR UPDATE happens before
ORDER BY or LIMIT normally, but that if the FOR UPDATE is inherited from
an outer query level, it happens
On Tue, 27 Oct 2009, Dimitri Fontaine wrote:
I parse the current status as always reading files in the
postgresql.conf.d directory located in the same place as the current
postgresql.conf file.
Way upthread I pointed out that what some packagers have really wanted for
a while now is to put
Robert Haas robertmh...@gmail.com writes:
If it doesn't have any effect anyway, what's the virtue of back-patching it?
Because 8.4 just fails in cases where we can easily allow it to work
according to the new definition. Right now, if you want to use FOR
UPDATE in a query that has WITHs, you
On Tue, 27 Oct 2009, Kevin Grittner wrote:
I have 200 clusters. I understand the proposal. I see no benefit to
me.
-Kevin, the troglodyte ;-)
It looks like we'll have to settle this the only way your kind understands
then: a battle to the death using clubs. See you at the next
Peter,
Right, but you'll notice that Josh already got his way into how the
current postgresql.conf is laid out and how the documentation is
structured. I can't find anything in the documentation anymore. Just
as a side note ... when we start giving people new ways to access the
On Tuesday 27 October 2009 18:02:53 Robert Haas wrote:
On Tue, Oct 27, 2009 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In yesterday's discussions about FOR UPDATE there was some mention of
making it not propagate into WITH subqueries:
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about the lack of consensus on that
is what will happen if different
Hi,
log file entries from running vacuumdb are double-spaced,
as vacuumdb ends the commands with ;\n (cf. attached mini-
patch). Is there a deeper meaning in that, or could it be
trimmed?
TIA,
Tim
Index: vacuumdb.c
===
RCS file:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
BTW, is it worth preventing such a crash putting an elog message in
trigger.c?
It doesn't seem right to allow a catalog change that results in an
assertion failure. Seems like we should
On Tue, Oct 27, 2009 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If it doesn't have any effect anyway, what's the virtue of back-patching it?
Because 8.4 just fails in cases where we can easily allow it to work
according to the new definition.
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
What I am thinking we should do is define that FOR UPDATE happens before
ORDER BY or LIMIT normally, but that if
On Tue, Oct 27, 2009 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about
On Tue, 2009-10-27 at 13:21 -0400, Tom Lane wrote:
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to more than
one.
One thing that concerns me a bit about the lack
Marcelo Costa marcelojsco...@gmail.com writes:
[ trying to defer RI_FKey_cascade_del trigger crashes the backend ]
I looked at this a bit more and think that there's more to it than pilot
error. The crash occurs because we queue a deferred trigger here:
#0 AfterTriggerSaveEvent
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote:
IME, the use case for multiple Apache configuration files is that
there are bits of configuration that support particular modules which
packagers want installed only in conjunction with the corresponding
modules - it
Greg Stark gsst...@mit.edu writes:
I still think a simple hard coded rule is more useful and than allowing
sysadmins to specify any regexp or glob and then having modules or
tools not know what's allowed or not.
Yeah. Considering that the entire argument for this feature is to
simplify
Hello,
I've been reading over the documentation to find an alternative to the
deprecated xpath_table functionality. I think it may be a possibility but
I'm not seeing a clear alternative.
Thanks,
Chris Graner
I wrote:
The crash occurs because we queue a deferred trigger here ...
when we are not inside any AfterTriggerBeginQuery/AfterTriggerEndQuery
pair. Normally _SPI_pquery() would take care of that detail, but it's
been specifically told not to by the RI trigger code (notice the
fire_triggers=0
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, the case would be something like
select * from
(select * from foo order by x limit n) ss
for update of ss;
That's a pretty odd construction.
Dunno
On Tue, 27 Oct 2009, Greg Stark wrote:
If they all had to edit the same file then they have to deal with
writing out values and also reading them back. Everyone would need a
config file parser and have to make deductions about what other tools
were trying to do and how to interact with them.
I wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, the case would be something like
select * from
(select * from foo order by x limit n) ss
for update of ss;
That's a pretty odd
Tim Landscheidt t...@tim-landscheidt.de writes:
log file entries from running vacuumdb are double-spaced,
as vacuumdb ends the commands with ;\n (cf. attached mini-
patch). Is there a deeper meaning in that, or could it be
trimmed?
There are a LOT of clients that tend to send queries with
Hi,
Phone quoting again...
--
dim
Le 27 oct. 2009 à 18:06, Greg Smith gsm...@gregsmith.com a écrit :
On Tue, 27 Oct 2009, Dimitri Fontaine wrote:
I parse the current status as always reading files in the
postgresql.conf.d directory located in the same place as the current
--
dim
Le 27 oct. 2009 à 18:21, Tom Lane t...@sss.pgh.pa.us a écrit :
Greg Smith gsm...@gregsmith.com writes:
... One file per GUC is certainly never going to fly though, it's
been hard enough getting people to accept going from one file to
more than
one.
One thing that concerns me
Chris Graner wrote:
Hello,
I've been reading over the documentation to find an alternative to the
deprecated xpath_table functionality. I think it may be a possibility
but I'm not seeing a clear alternative.
Thanks,
Chris Graner
The standard is XMLTABLE and is implemented by both db2 and
On Tue, Oct 27, 2009 at 12:43 PM, Josh Berkus j...@agliodbs.com wrote:
Merlin,
Why even bother with a hash function when you can just have multiple
table pull from a shared sequence? AFAICT, this solves the OP's
problem with no downsides (I used the approach with excellent results
in a
On Oct 27, 2009, at 4:37 PM, Merlin Moncure wrote:
'as is', advisory locks is a fantastic feature that can be used for
signaling, mutexing, etc that are relatively difficult things to do in
the transactional world of sql. My main gripe is that the 'shared id'
method for doing record
On Tue, Oct 27, 2009 at 2:59 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas robertmh...@gmail.com wrote:
IME, the use case for multiple Apache configuration files is that
there are bits of configuration that support particular modules which
packagers want
On Mon, Oct 26, 2009 at 11:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
On Tuesday 27 October 2009 00:42:39 Tom Lane wrote:
I think a design that is limited to a prespecified set of GUCs is
broken by definition. It'd be better to make it work like
ALTER
Robert,
The Apache model is definitely the first of these, AFAICS. The
proposals on this thread mostly seem to be an amalgam of both, which
doesn't strike me as a terribly good idea, but evidently I'm in the
minority.
Well, an individual DBA would not want to do it both ways. But we
should
Robert Haas robertmh...@gmail.com writes:
I confess that I'm a bit mystified about the design of the reloptions
stuff. It seems kind of odd to store structured data as text[]; it's
kind of the opposite of what I would normally recommend as good
database design.
It's definitely a bit EAV-ish
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I confess that I'm a bit mystified about the design of the
reloptions stuff. It seems kind of odd to store structured data as
text[]; it's kind of the opposite of what I would normally
Hi,
On Tue, Oct 27, 2009 at 4:53 PM, Andreas Schmidt a.schm...@mdtec.de wrote:
Hi, thank you for your response.
But does this mean, that only WinXP is no supported or doesn't it work at
all? I would need it on a Windows2003Server???
According to the previous post, pg_standby in v8.3.7 would
David Fetter escribió:
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I confess that I'm a bit mystified about the design of the
reloptions stuff. It seems kind of odd to store structured data as
text[]; it's kind of the opposite of
On Tue, Oct 27, 2009 at 9:20 PM, David Fetter da...@fetter.org wrote:
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I confess that I'm a bit mystified about the design of the
reloptions stuff. It seems kind of odd to store structured data
Robert Haas robertmh...@gmail.com writes:
For things like autovacuum options, the actual representation probably
doesn't matter much because I'm guessing that the amount of work being
done by vacuum dwarfs the parsing cost, and it's a background task
anyway. But this seems like a less solid
pg_read_file() takes byte-offset and length as arguments,
but we don't check the result text with pg_verify_mbstr().
Should pg_read_file() return bytea instead of text or adding
some codes to verify the input? Only superusers are allowed
to use the function, but it is still dangerous.
If we
On Tue, Oct 27, 2009 at 9:05 PM, Josh Berkus j...@agliodbs.com wrote:
The Apache model is definitely the first of these, AFAICS. The
proposals on this thread mostly seem to be an amalgam of both, which
doesn't strike me as a terribly good idea, but evidently I'm in the
minority.
Well, an
Robert Haas robertmh...@gmail.com writes:
I guess all I'm saying is that if we took the approach of making SET
PERSISTENT rewrite postgresql.conf, we actually could let people do it
either way they pleased without the complexity of having multiple
files.
You keep saying that, but what you
On Tue, Oct 27, 2009 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
For things like autovacuum options, the actual representation probably
doesn't matter much because I'm guessing that the amount of work being
done by vacuum dwarfs the parsing cost,
Now I'm working on writing a documentation from the viewpoint of
developers as follows (It is a work in progress):
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/README
Is there any differences between what I want to describe and what you
want to know?
On Tue, Oct 27, 2009 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I guess all I'm saying is that if we took the approach of making SET
PERSISTENT rewrite postgresql.conf, we actually could let people do it
either way they pleased without the
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that anything without pg_dump support would be even vaguely OK...
...Robert
--
Sent via pgsql-hackers mailing list
Folks,
I'm looking at the developer docs on our site, and I couldn't find any
docs for the following features:
Column Triggers
Calling Named Function parameters
DEFAULT privileges
... without docs, we really can't expect people to test them. Do we
have partial docs for these? Am I not looking
On 10/27/09 8:24 PM, Robert Haas wrote:
read the old postgresql.conf and
write it back out to a new file line by line. If, in the process of
doing this, you find a setting for the variable you're trying to
change, then write out the new line in place of the original line.
You've hit the
Josh Berkus j...@agliodbs.com writes:
I'm looking at the developer docs on our site, and I couldn't find any
docs for the following features:
Column Triggers
http://developer.postgresql.org/pgdocs/postgres/sql-createtrigger.html
Calling Named Function parameters
Robert Haas wrote:
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that anything without pg_dump support would be even vaguely OK...
In my previous experience, it
Tom,
I'm looking at the developer docs on our site, and I couldn't find any
docs for the following features:
Column Triggers
http://developer.postgresql.org/pgdocs/postgres/sql-cre
atetrigger.html
OK, this is the genuine failure; the syntax is missing for column triggers:
CREATE
Josh Berkus j...@agliodbs.com writes:
OK, this is the genuine failure; the syntax is missing for column triggers:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE function_name ( arguments )
It's embedded in
On Tue, 27 Oct 2009, Robert Haas wrote:
I guess I didn't consider the possibility that someone might reuse an
8.4 postgresql.conf on an 8.5 server. That could be awkward.
Happens all the time, and it ends up causing problems like people still
having settings for GUCs that doesn't even exist
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
You're hearing from the people who are working on tools: requiring that
any tool parse a hand-written config file is a non-starter.
It can be done, pgadmin actually does it currently. But I totally
agree it's a bad idea.
But
78 matches
Mail list logo
