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
---+-+---
page_na
"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 n
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 th
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
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 dro
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'
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
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 o
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 "subt
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 the
"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 S
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 i
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
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 somethin
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
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
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 to
"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 kern
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 on
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 = 'cinnamon';
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 accum
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 somethin
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
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
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 cours
"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 pat
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
> Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in
> D
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
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 unlike
"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
> inconsiste
"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
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
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-fil
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 though
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 create
-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
36 matches
Mail list logo
