On Dec 11, 2012 9:28 PM, "David Gould" wrote:
>
> Thank you. I got the example via cut and paste from email and pasted it
> into psql on different hosts. od tells me it ends each line with:
>
> \n followed by 0xC2 0xA0 and then normal spaces. The C2A0 thing is
> apparently NO-BREAK SPACE. Invi
On Sun, Dec 09, 2012 at 02:09:21PM -0500, Matthew Gerber wrote:
> In this situation, st_transform throws an internal_error, which my
> function catches and returns NULL for. The error / crash is not caused by a
> NULL argument; rather, it is caused by the final value in the attached
> script's INSE
On Fri, Dec 14, 2012 at 04:20:30PM -0500, Tom Lane wrote:
> /* Determine whether message is enabled for server log output */
> if (IsPostmasterEnvironment)
> output_to_server = is_log_level_output(elevel, log_min_messages);
> else
> /* In bootstrap/standalone case, do no
Hi,
attached is a new version of the patch that
(a) converts the 'log_step_seconds' variable to a constant (and does
not allow changing it using a command-line option etc.)
(b) keeps the current logging as a default
(c) adds a "-q" switch that enables the new logging with a 5-second
int
Hi,
I've updated the patch to include the optimization described in the
previous post, i.e. if the number of relations is below a certain
threshold, use a simple for loop, for large numbers of relations use
bsearch calls.
This is done by a new constant BSEARCH_LIMIT, which is set to 10 in the
pat
On 12/16/2012 12:51:06 AM, Peter Eisentraut wrote:
> I'm going to set this patch as returned with feedback for now.
Ok. At this point I don't have a vision for improving it
so it might sit there untouched. Maybe someone else
will step forward and make it better.
Regards,
Karl
Free Software:
On 12/16/2012 10:23 PM, Peter Eisentraut wrote:
On Sun, 2012-12-16 at 19:13 +0100, Hannu Krosing wrote:
As an idea seems quite good, but maybe the "run once" part could use
its
own keyword in the future, something like PREPARE or REQUIRE?
Well, either we do it in a language independent way, in
On 12/16/2012 12:56:22 AM, Peter Eisentraut wrote:
> On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
> > On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
> > > On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
> > > > On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
> > > > > This patch
On Fri, Dec 14, 2012 at 1:34 AM, Alexander Korotkov wrote:
> On Mon, Dec 3, 2012 at 4:31 PM, Alexander Korotkov
> wrote:
>
>> Actually, I generally dislike path matrix for same reasons. But:
>> 1) Output graphs could contain trigrams which are completely useless for
>> search. For example, for re
On Sun, 2012-12-16 at 13:03 -0500, Tom Lane wrote:
> Sure, but wouldn't it be cleaner to do that via some language-specific
> syntax inside the function string? I'm imagining some syntax like
>
> CREATE FUNCTION ... AS $$
> global[ some definitions here ]
> function code h
On Sun, 2012-12-16 at 19:13 +0100, Hannu Krosing wrote:
> As an idea seems quite good, but maybe the "run once" part could use
> its
> own keyword in the future, something like PREPARE or REQUIRE?
Well, either we do it in a language independent way, in which case this
would be too prescriptive, or
On 12/16/2012 08:44 PM, Andrew Dunstan wrote:
On 12/16/2012 01:37 AM, Peter Eisentraut wrote:
So in practice this might look like this:
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;
Bleah.
It seems obscure to say the least.
Why not have
On 12/16/2012 01:37 AM, Peter Eisentraut wrote:
So in practice this might look like this:
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;
Bleah.
It seems obscure to say the least.
Why not have something along the lines of plperl's on_init
On 12/16/2012 07:37 PM, Tom Lane wrote:
Hannu Krosing writes:
On further thought the function name should just be what it is defined
in postgresql, like this
CREATE FUNCTION foo(a,b,c) AS $$
import x
from __future__ import nex_cool_feature
def helper_function(x):
On 12/16/2012 07:44 PM, Tom Lane wrote:
Hannu Krosing writes:
On further thought the function name should just be what it is defined
in postgresql, like this
CREATE FUNCTION foo(a,b,c) AS $$
def foo(a,b,c):
BTW, how well will that play with overloaded function names? I don't
particula
Hannu Krosing writes:
>> On further thought the function name should just be what it is defined
>> in postgresql, like this
>> CREATE FUNCTION foo(a,b,c) AS $$
>> def foo(a,b,c):
BTW, how well will that play with overloaded function names? I don't
particularly care for saying that PL/Pyth
Hannu Krosing writes:
> On further thought the function name should just be what it is defined
> in postgresql, like this
> CREATE FUNCTION foo(a,b,c) AS $$
> import x
> from __future__ import nex_cool_feature
> def helper_function(x):
> ...
> def fo
On 12/16/2012 07:20 PM, Hannu Krosing wrote:
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut writes:
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_12345():
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut writes:
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_12345():
source code here
---
It would be useful to b
Magnus Hagander writes:
> On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers wrote:
>> That would make such a truncation less frequent, and after all a truncated
>> display is not
>> particular useful.
> Agreed - it's useful during testing, but not in a typical production
> use. It might actually be
On 12/16/2012 07:37 AM, Peter Eisentraut wrote:
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" t
Peter Eisentraut writes:
> When you do
> CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
> AS $$
> source code here
> $$;
> it internally creates a "source file" that contains
> ---
> def __plpython_procedure_foo_12345():
> source code here
> ---
> It would be useful to be able to do somet
On Sun, 2012-12-16 at 10:20 +0100, Pavel Stehule wrote:
> Hello
>
> I understand to motivation, but proposed syntax is not too intuitive and
> robust
>
> can you do it in one function and call import only in first call?
Sometimes, but it's even less intuitive and robust.
--
Sent via pgsql-h
Pavan Deolasee writes:
> On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs wrote:
>> As explained above, I disagree that it looks like a good idea, and
>> you've shown no evidence it would be or is true.
> Lets separate out these two issues. What you are suggesting as a
> follow up to Tom's idea, I'v
On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers wrote:
> On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
>> On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers wrote:
>>> from 9.3devel (this morning):
>>
>>
>>> The truncated name in parentheses only shows up during the filling of the
>>> new PG
On 2012-12-16 16:44:04 +, Simon Riggs wrote:
> On 13 December 2012 20:03, Andres Freund wrote:
>
> > Does anybody have an opinion on the attached patches? Especially 0001,
> > which contains the procarray changes?
> >
> > It moves a computation of the sort of:
> >
> > result -= vacuum_defer_cl
On 13 December 2012 20:03, Andres Freund wrote:
> Does anybody have an opinion on the attached patches? Especially 0001,
> which contains the procarray changes?
>
> It moves a computation of the sort of:
>
> result -= vacuum_defer_cleanup_age;
> if (!TransactionIdIsNormal(result))
>result = F
On 2012-12-16 16:25:03 +, Simon Riggs wrote:
> On 16 December 2012 14:41, Andres Freund wrote:
> > On 2012-12-16 13:23:56 +0530, Pavan Deolasee wrote:
> >> Another idea could have been to NOT clear the visibility bit when a
> >> HOT update happens. Such tuple can get pruned by HOT prune, so we
On 8.12.2012 03:08, Jeff Janes wrote:
> On Thu, Dec 6, 2012 at 3:52 PM, Tomas Vondra wrote:
>> Hi,
>>
>> On 6.12.2012 23:45, MauMau wrote:
>>> From: "Tom Lane"
Well, that's unfortunate, but it's not clear that automatic recovery is
possible. The only way out of it would be if an undama
On 16 December 2012 14:41, Andres Freund wrote:
> On 2012-12-16 13:23:56 +0530, Pavan Deolasee wrote:
>> Another idea could have been to NOT clear the visibility bit when a
>> HOT update happens. Such tuple can get pruned by HOT prune, so we
>> don't need vacuum per se, and the index-only scans ar
On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs wrote:
>
>
> As explained above, I disagree that it looks like a good idea, and
> you've shown no evidence it would be or is true.
>
Lets separate out these two issues. What you are suggesting as a
follow up to Tom's idea, I've no objection to that and
On 12/16/2012 01:29 AM, Peter Eisentraut wrote:
On Fri, 2012-12-14 at 17:03 -0500, Tom Lane wrote:
Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
can control it, or so that somebody can inject a different behavior
if they want.
You could also (or at least additionally) map !U
On 2012-12-15 01:19:26 +0100, Andres Freund wrote:
> On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
> > On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund
> > wrote:
> > > Just moving that tidbit inside the lock seems to be the pragmatic
> > > choice. GetOldestXmin is called
> > >
> > > * once per
On 2012-12-15 16:48:08 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Doing that only makes sense when we're running a SELECT. Setting the
> > all visible bit immediately prior to an UPDATE that clears it again is
> > pointless effort, generating extra work for no reason.
>
> On the other hand,
On 2012-12-16 13:23:56 +0530, Pavan Deolasee wrote:
> Another idea could have been to NOT clear the visibility bit when a
> HOT update happens. Such tuple can get pruned by HOT prune, so we
> don't need vacuum per se, and the index-only scans are not affected
> because the update was a HOT update,
On 27 November 2012 22:41, Tom Lane wrote:
> Merlin Moncure writes:
>> ... I think if you relaxed
>> the function sigs of a few functions on this page
>> (http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
>> most reported problems would go away.
>
> That's an interesting way
Hi,
Now that XLRecPtr's are plain 64bit integers what are we supposed to use
in code comparing and manipulating them? There already is plenty example
of both, but I would like new code to go into one direction not two...
I personally find direct comparisons/manipulations far easier to read
than t
On Wed, Dec 12, 2012 at 8:07 AM, Craig Ringer wrote:
> Hi all
>
> There's an issue with MSVC builds on Windows where clean.bat deletes
> src\include\utils\fmgroids.h (as it should) but build.pl doesn't
> re-create it reliably.
>
> It's created fine on the first build because Gen_fmgrtab.pl is call
On 12/14/2012 3:20 PM, Robert Haas wrote:
On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane wrote:
Robert Haas writes:
... In more
than ten years of working with PostgreSQL, I've never encountered
where the restriction at issue here prevented a bug. It's only
annoyed me and broken my application co
On 16 December 2012 07:53, Pavan Deolasee wrote:
> On Sun, Dec 16, 2012 at 3:18 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> Doing that only makes sense when we're running a SELECT. Setting the
>>> all visible bit immediately prior to an UPDATE that clears it again is
>>> pointless effort, gen
Hello
I understand to motivation, but proposed syntax is not too intuitive and robust
can you do it in one function and call import only in first call?
Regards
Pavel
2012/12/16 Peter Eisentraut :
> I'm going to use PL/Python as an example, but I would also like to know
> if this could be appl
On Sun, Dec 16, 2012 at 12:23 AM, Pavan Deolasee
wrote:
>
> "When a file is secondary, make will not create the file merely
> because it does not already exist, but make does not automatically
> delete the file."
> (link:
> ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html#
42 matches
Mail list logo
