-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Sep 01, 2007 at 12:57:35AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Hm. I've come to expect the OS removing all pidfiles early at bootup.
If there's a script in your system that does that, then adding Postgres
lockfiles to it
I believe we had consensus that 8.3 needs to include an easier way for a
function to set a local value of search_path, as proposed here:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php
I've been holding off actually implementing that because adding a column
to pg_proc would
Just a minor doc upgrade. I've linked a couple of the more prominent
mentions of escape string syntax in Functions and Operators /
Pattern Matching back to the section on SQL string literals, which
explains how escape syntax works.
I considering linking all mentions of escape syntax, but thought
August Zajonc [EMAIL PROTECTED] writes:
I do have a question about jamming though. Will the system work if the
file ended up stuck in this folder? Let's say the move destination has a
duplicate file that conflicts, or permissions change under you, or disks
fill.
Yeah, the move-the-file
On 9/2/07, Tom Lane [EMAIL PROTECTED] wrote:
I thought about ways to include GUC settings directly into CREATE
FUNCTION, but it seemed pretty ugly and inconsistent with the
existing syntax. So I'm thinking of supporting only the above
syntaxes, meaning it'll take at least two commands to
Tom Lane [EMAIL PROTECTED] writes:
I thought about ways to include GUC settings directly into CREATE
FUNCTION, but it seemed pretty ugly and inconsistent with the
existing syntax. So I'm thinking of supporting only the above
syntaxes, meaning it'll take at least two commands to create a
Brendan Jurd [EMAIL PROTECTED] writes:
CREATE FUNCTION foo(int) RETURNS int AS $$
...
$$
LANGUAGE plpgsql
STABLE
STRICT
SECURITY DEFINER
RESET search_path
SET regex_flavor = 'cinnamon';
That doesn't seem especially horrible. In what way do you feel it is
inconsistent with
Gregory Stark [EMAIL PROTECTED] writes:
I think security definer functions should automatically inherit their
search_path. The whole secure by default thing.
This assumes that the search path at creation time has something to do
with the path you'd like to use at execution, which is unlikely to
Tom Lane wrote:
I had an idea this morning that might be useful: back off the strength
of what we try to guarantee. Specifically, does it matter if we leak a
file on crash, as long as it isn't occupying a lot of disk space?
(I suppose if you had enough crashes to accumulate many thousands of
Hi Tom and Andrew,
On Thu, 30 Aug 2007, Tom Lane wrote:
Date: Thu, 30 Aug 2007 10:04:34 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], PostgreSQL-development pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I think security definer functions should automatically inherit their
search_path. The whole secure by default thing.
This assumes that the search path at creation time has something to do
with the path you'd like to
On Sat, 2007-09-01 at 12:41 -0400, Tom Lane wrote:
A few days ago, Simon suggested that we should generalize this notion
to allow per-function settings of any GUC variable:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php
My reaction to that was more or less D'oh, of course!
Jeff Davis [EMAIL PROTECTED] writes:
Can we also provide syntax which would be equivalent to setting var
for the function to be whatever the current value happens to be when the
ALTER FUNCTION is run? Possible syntax might be something like:
ALTER FUNCTION func(args) SET var TO CURRENT;
Hmmm
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
This assumes that the search path at creation time has something to do
with the path you'd like to use at execution, which is unlikely to be
the case in existing pg_dump output, to name one example. I don't
really
On 9/1/07, Tom Lane [EMAIL PROTECTED] wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Can we also provide syntax which would be equivalent to setting var
for the function to be whatever the current value happens to be when the
ALTER FUNCTION is run? Possible syntax might be something like:
Heikki Linnakangas wrote:
Tom Lane wrote:
I had an idea this morning that might be useful: back off the strength
of what we try to guarantee. Specifically, does it matter if we leak a
file on crash, as long as it isn't occupying a lot of disk space?
(I suppose if you had enough crashes to
On Sep 1, 2007, at 1:36 PM, Brendan Jurd wrote:
So if we integrated the GUC settings into CREATE FUNCTION, we'd end up
writing something like
CREATE FUNCTION foo(int) RETURNS int AS $$
...
$$
LANGUAGE plpgsql
STABLE
STRICT
SECURITY DEFINER
RESET search_path
SET regex_flavor =
August Zajonc wrote:
Yes, checkpoints would need to include a list of
created-but-yet-uncommitted
files. I think the hardest part is figuring out a way to get that
information
to the backend doing the checkpoint - my idea was to track them in shared
memory, but that would impose a hard limit
Florian G. Pflug [EMAIL PROTECTED] writes:
It might be even worse - I'm not sure that a rename is an atomic operation
on most filesystems.
rename(2) is specified to be atomic by POSIX, but relinking a file into
a different directory can hardly be --- it's not even provided as a
single kernel
Florian G. Pflug wrote:
August Zajonc wrote:
I'm confused about this.
As long as we assert the rule that the file name can't change on the
move, then after commit the file can be in only one of two places.
The name of the file is known (ie, pg_class). The directories are
known. What needs
Tom Lane wrote:
What I was thinking about was a flag file separate from the data file
itself, a bit like what we use for archiver signaling. If is the
new data file, then touch .new to mark the file as needing to be
deleted on restart. Remove these files just *before* commit. This
On Sat, Sep 01, 2007 at 03:03:14PM -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Can we also provide syntax which would be equivalent to setting var
for the function to be whatever the current value happens to be when the
ALTER FUNCTION is run? Possible syntax might be
On 9/1/07, Tom Lane [EMAIL PROTECTED] wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Can we also provide syntax which would be equivalent to setting var
for the function to be whatever the current value happens to be when the
ALTER FUNCTION is run? Possible syntax might be something like:
On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote:
I believe we had consensus that 8.3 needs to include an easier way for a
function to set a local value of search_path, as proposed here:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php
I've been holding off actually
David Fetter [EMAIL PROTECTED] writes:
On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote:
The most straightforward way to support this syntactically seems to
be to follow the per-user and per-database GUC setting features:
ALTER FUNCTION func(args) SET var = value
Would it be hard
Marko Kreen [EMAIL PROTECTED] writes:
On 9/1/07, Tom Lane [EMAIL PROTECTED] wrote:
One problem is that we'd have to make CURRENT a reserved word to make it
work exactly like that. Can anyone think of a variant syntax that
doesn't need a new reserved word?
SET var FROM CURRENT SESSION
Seems
On Thu, Aug 30, 2007 at 10:34:42PM +0100, Simon Riggs wrote:
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.
It would be good if there
So I coded up a patch for this, based on the idea of creating a
quasi-subtransaction that affects only GUC while entering/exiting a
function that has GUC settings attached. The specified settings are
applied as if by SET LOCAL before starting function execution, and then
they drop out during
David Fetter [EMAIL PROTECTED] writes:
While we're at it, it would be very nice to be able to set default
per-role, per-database settings.
Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET?
regards, tom lane
---(end of
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
It might be even worse - I'm not sure that a rename is an atomic operation
on most filesystems.
rename(2) is specified to be atomic by POSIX, but relinking a file into
a different directory can hardly be --- it's not even provided as
On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
While we're at it, it would be very nice to be able to set default
per-role, per-database settings.
Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET?
You can't set
Tom Lane wrote:
So I coded up a patch for this, based on the idea of creating a
quasi-subtransaction that affects only GUC while entering/exiting a
function that has GUC settings attached. The specified settings are
applied as if by SET LOCAL before starting function execution, and then
they
David Fetter [EMAIL PROTECTED] writes:
On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote:
Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET?
You can't set both at once.
Oh, you mean the cross-product case. Sorry, that was on the wish-list
already, but no one
On Sat, Sep 01, 2007 at 11:07:55PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote:
Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET?
You can't set both at once.
Oh, you mean the
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
rename(2) is specified to be atomic by POSIX, but relinking a file into
a different directory can hardly be --- it's not even provided as a
single kernel call, is it?
I'd have thought that they only guarantee that if the new name
There seems to be some behavior change in current CVS with respect to
gist and gin indexes on varchar[]. Some side effect of the tsearch2
merge?
\d search_pages
Table public.search_pages
Column |Type | Modifiers
---+-+---
36 matches
Mail list logo
