On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Hi,
On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
Hello,
the purpose of this patch is to limit impact of pg_backup on running
On 2013-08-21 08:10:42 +0200, PostgreSQL - Hans-Jürgen Schönig wrote:
On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Hi,
On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
On 08/14/2013 11:27 PM, Bruce Momjian wrote:
On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
Attached are docs that add the new syntax, and mention it is
non-standard; you can see the output here:
Eureka.
The problem is solved.
Bambo:
I guess you forget to convert
you string to UTF-8 before insert.
No, too many conversions :)
The
fact is that in the source code the query was casted to UnicodeString,
because of previous requirements on the project:
//tmp is a char* and
contains the
On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
select distinct x from ... ;
select x from
On Wed, Aug 21, 2013 at 12:32:20PM +0200, Vik Fearing wrote:
On 08/14/2013 11:27 PM, Bruce Momjian wrote:
On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
Attached are docs that add the new syntax, and mention it
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The bottom line was:
It looks like our choices are (1) teach configure to enable
On Tue, Aug 20, 2013 at 8:53 PM, David E. Wheeler da...@justatheory.comwrote:
On Aug 20, 2013, at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You need more parentheses -- (source::text) would've worked.
Alas, no, same problem as for CAST():
ERROR: functions in index expression must be
Hi,
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
=# create function foof() returns void as $$ begin raise exception
'foo'; end $$ language plpgsql;
CREATE FUNCTION
=# create function bar() returns void as $$ begin perform foof(); end $$
language
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
2013/8/21 Marko Tiikkaja ma...@joh.to
Hi,
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
=# create function foof() returns void as $$ begin raise exception 'foo';
end $$ language plpgsql;
CREATE FUNCTION
=# create function bar() returns void as
On 8/21/13 2:28 PM, I wrote:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
An even worse example:
=# create function foof() returns void as $$ begin raise exception
'foo'; end $$ language plpgsql;
CREATE FUNCTION
=# create function barf() returns
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
It used to do so, in the beginning when we first added context-printing.
There were complaints that the result was too verbose; for instance if you
had a RAISE NOTICE
Alexander Korotkov aekorot...@gmail.com writes:
It seems reasonable to me to cast enum to oid. However, creating casts
without function isn't allowed for enums.
test=# create cast (source as oid) without function;
ERROR: enum data types are not binary-compatible
The reason for that is you'd
On 8/21/13 4:22 PM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
It used to do so, in the beginning when we first added context-printing.
There were complaints that the result was too verbose; for
Hello,
One of my colleagues, who is relatively new to PostgreSQL, asked me if
PostgreSQL supports Solaris 11. The reason why he had this question is that
the following page says Solaris 10 instead of Solaris 10 and later.
http://www.postgresql.org/docs/devel/static/kernel-resources.html
Stephen Frost sfr...@snowman.net wrote:
Yeah, I've been thinking about this a bit also and agree that 9.3
is fine but not farther back.
+1 to 9.3 but no farther back.
I would be in favor of going farther back if there were not fairly
obvious workarounds for the OOM problems that lack of
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
ISTM you want some kind of hybrid setting like:
#include_system auto.conf
which simultaneously does three things:
1. Sets the enable_alter_system flag
2. Indicates the file to use
3. Indicates the priority of the setting re
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
It used to do so, in the beginning when we first added context-printing.
There were complaints that
On 8/21/13 5:05 PM, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
It used to do so, in the beginning when we first added
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja ma...@joh.to wrote:
On 8/21/13 5:05 PM, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement,
On Aug 21, 2013, at 4:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
test=# create cast (source as oid) without function;
ERROR: enum data types are not binary-compatible
The reason for that is you'd get randomly different results on another
installation. In this particular application, I
2013/8/21 Merlin Moncure mmonc...@gmail.com
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja ma...@joh.to wrote:
On 8/21/13 5:05 PM, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja ma...@joh.to writes:
By default, PL/pgSQL
On 2013-08-21 17:18, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja ma...@joh.to wrote:
Why does \set VERBOSITY 'terse' not work for you?
Because it can't be controlled mid-function...that would suppress all
context of errors as well as messages and so it's useless.
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja ma...@joh.to wrote:
Why does \set VERBOSITY 'terse' not work for you?
Because it can't be controlled mid-function...that would suppress all
context of errors as well as messages and so it's useless.
On Wed, Aug 21, 2013 at 4:05 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:2001:26: warning: ‘before_index’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
On Wed, Aug 21, 2013 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja ma...@joh.to wrote:
Why does \set VERBOSITY 'terse' not work for you?
Because it can't be controlled mid-function...that would
2013-08-21 19:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:2001:26: warning: ‘before_index’ may be used
2013-08-21 20:00 keltezéssel, Boszormenyi Zoltan írta:
2013-08-21 19:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2013-08-20 21:06 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
Here's a new one, for v7:
setrefs.c: In function ‘set_plan_refs’:
W dniu 21.08.2013 19:17, Boszormenyi Zoltan pisze:
With this fixed, a more complete review:
Thanks.
There is a new regression test (returning_before_after.sql) covering
this feature. However, I think it should be added to the group
where returning.sql resides currently. There is a value in
Hi,
2013-08-21 20:52 keltezéssel, Karol Trzcionka írta:
W dniu 21.08.2013 19:17, Boszormenyi Zoltan pisze:
With this fixed, a more complete review:
Thanks.
There is a new regression test (returning_before_after.sql) covering
this feature. However, I think it should be added to the group
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do have a system identifier but it's not
very accessible.
The attached patch implements a pg_system_identifier() function that
exposes it.
Shall I add this to the next commitfest?
--
Vik
***
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
It looks like our choices are (1) teach configure to enable
-fno-aggressive-loop-optimizations if the compiler recognizes it,
or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9.
I am in
On Wed, 2013-03-27 at 23:25 +0100, Pavel Stehule wrote:
I redesigned output from plpgsql_check_function. Now, it returns table
everytime.
Litlle bit code simplification.
This patch is in the 2013-09 commitfest but needs a rebase.
--
Sent via pgsql-hackers mailing list
This patch is in the 2013-09 commitfest but needs a rebase.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
I've attached a revised version that fixes the issues above:
This patch is in the 2013-09 commitfest but needs a rebase.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, 2013-08-12 at 15:27 +0100, Dean Rasheed wrote:
Attached is a work-in-progress patch to extend auto-updatable views to
support views containing a mix of updatable and non-updatable columns.
This is basically the columns part of SQL Feature T111, Updatable
joins, unions, and columns.
but needs a rebase.
See attached - thanks!
lead-lag-ignore-nulls.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
Given that, I'm fine with just bumping the version on borka to that
version. Any objections?
This was not done for 9.3rc1, AFAICT. Let's please do it for the next
release builds.
--
Sent via pgsql-hackers mailing list
On Mon, Aug 19, 2013 at 08:46:11AM -0500, Michael Cronenworth wrote:
On 08/17/2013 12:16 AM, Noah Misch wrote:
1. Redefine those constants for more (all?) compilers.
2. Remove that block and put #ifdef around all usage of such constants in
frontend code, as you have done.
3. Remove that
On Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
Alexander Korotkov aekorot...@gmail.com writes:
It seems reasonable to me to cast enum to oid. However, creating casts
without function isn't allowed for enums.
test=# create cast (source as oid) without function;
ERROR: enum
On Wed, Aug 21, 2013 at 8:22 PM, Stephen Frost sfr...@snowman.net wrote:
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
ISTM you want some kind of hybrid setting like:
#include_system auto.conf
which simultaneously does three things:
1. Sets the enable_alter_system flag
2.
On Aug 21, 2013, at 10:57 AM, Andres Freund wrote:
On 2013-08-21 08:10:42 +0200, PostgreSQL - Hans-Jürgen Schönig wrote:
On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
2013-08-19 19:20 keltezéssel, Andres Freund írta:
Hi,
On
44 matches
Mail list logo
