On Wed, 2009-10-28 at 00:25 -0400, Tom Lane wrote:
> Josh Berkus 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 PROCEDUR
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus 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 the difficulty
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
Josh Berkus 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 "event", which
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:
CRE
Robert Haas wrote:
> 2009/10/27 KaiGai Kohei :
>> - 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 enabled to reduce
Josh Berkus 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
http://developer.postgresql.org/pgdocs/
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
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 lookin
2009/10/27 KaiGai Kohei :
> - 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 (pgsql-hackers@postgres
On Tue, Oct 27, 2009 at 10:53 PM, Tom Lane wrote:
> Robert Haas 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.
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? I
On Tue, Oct 27, 2009 at 10:18 PM, Tom Lane wrote:
> Robert Haas 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
>> anyw
Robert Haas 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 don't seem to get is
On Tue, Oct 27, 2009 at 9:05 PM, Josh Berkus 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 individual
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 leave
Robert Haas 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 argument for things
On Tue, Oct 27, 2009 at 9:20 PM, David Fetter wrote:
> On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
>> Robert Haas 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
David Fetter escribió:
> On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
> > Robert Haas 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 wou
Hi,
On Tue, Oct 27, 2009 at 4:53 PM, Andreas Schmidt 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 work file.
How a
On Tue, Oct 27, 2009 at 09:13:29PM -0400, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 :-(. But I don't s
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
sho
On Mon, Oct 26, 2009 at 11:07 PM, Tom Lane wrote:
> Andres Freund 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 DATABASE SET.
>
>> How sh
On Tue, Oct 27, 2009 at 2:59 PM, Greg Stark wrote:
> On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas 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 w
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 pessimistic
On Tue, Oct 27, 2009 at 12:43 PM, Josh Berkus 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 ported cobol
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
--
dim
Le 27 oct. 2009 à 18:21, Tom Lane a écrit :
Greg Smith 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 th
Hi,
Phone quoting again...
--
dim
Le 27 oct. 2009 à 18:06, Greg Smith 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
postgresql.conf file.
Way upthrea
Tim Landscheidt 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 trailing
newlines;
I wrote:
> Robert Haas writes:
>> On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane 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 why you th
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.
E
Robert Haas writes:
> On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane 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 why you think that. That's e
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_trigge
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
Greg Stark 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 matters for automat
On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas 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 has nothing to do wi
Marcelo Costa 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 (relinfo=0x40181778, event=1, row_trig
On Tue, 2009-10-27 at 13:21 -0400, Tom Lane wrote:
> Greg Smith 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 Tue, Oct 27, 2009 at 1:21 PM, Tom Lane wrote:
> Greg Smith 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
On Tue, Oct 27, 2009 at 1:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane 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
On Tue, Oct 27, 2009 at 1:14 PM, Tom Lane wrote:
> Robert Haas 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
> U
Robert Haas 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 either prevent th
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:
Greg Smith 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 config-adjustment tool
On Tuesday 27 October 2009 18:02:53 Robert Haas wrote:
> On Tue, Oct 27, 2009 at 10:50 AM, Tom Lane 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.p
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
> configu
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 conferen
Robert Haas 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 have to carefully write
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 th
Robert Haas writes:
> On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane 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 after the sub-select's ORDER BY or
>>
Greg Smith 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 counties that fil
On Tue, Oct 27, 2009 at 10:50 AM, Tom Lane 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 foo) SELECT * F
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:41 AM, Euler Taveira de Oliveira
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 m
On Tue, Oct 27, 2009 at 11:22 AM, Tom Lane wrote:
> I wrote:
>>> Robert Haas 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 o
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 yo
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 such
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 pgsq
I wrote:
>> Robert Haas 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 UPDATE into
> W
Alvaro Herrera escreveu:
> Tom Lane escribió:
>> Greg Stark 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 to
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 or
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 p
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 connect
Itagaki Takahiro wrote:
>
> Jeff Davis 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 toast.fillfactor.
On Mon, Oct 26, 2009 at 4:30 PM, Josh Berkus 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 downsides (I used
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, ass
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
Merlin Moncure wrote:
On Mon, Oct 26, 2009 at 11:18 PM, Andrew Dunstan 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
On Mon, Oct 26, 2009 at 11:18 PM, Andrew Dunstan 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 in plv
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 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
> > >> mor
On Mon, Oct 26, 2009 at 7:02 PM, Chris Browne 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 fairly minisc
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 fr
Hi,
Greg Smith 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 this:
>
> include
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 (pgsql-hackers@po
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 0
On Mon, 2009-10-26 at 14:13 -0700, Greg Stark wrote:
> On Mon, Oct 26, 2009 at 1:40 PM, Josh Berkus 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. memory.conf,
78 matches
Mail list logo
