Noah Misch writes:
> On Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
>> The reason for that is you'd get randomly different results on another
>> installation. In this particular application, I think David doesn't
>> really care about what values he gets as long as they're distinct,
>>
2013/8/21 Jim Nasby
> On 8/12/13 1:08 PM, Pavel Stehule wrote:
>
>>IF (bytes != LENGTH($1)) THEN
>> RAISE EXCEPTION 'Not all data copied to blob';
>>END IF;
>>PERFORM lo_close(fd);
>>
>
> FWIW, it's probably better to close before raising the exception...
>
it should to be done
Peter Eisentraut writes:
> 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.
Um ... touching borka
On 7/26/13 7:32 AM, Tom Lane wrote:
Greg Smith writes:
On 7/26/13 5:59 AM, Hannu Krosing wrote:
Well, SSD disks do it in the way proposed by didier (AFAIK), by putting
"random"
fs pages on one large disk page and having an extra index layer for
resolving
random-to-sequential ordering.
If yo
On 8/5/13 10:18 PM, Craig Ringer wrote:
The main issue with the test is that it's a dirty hack. What I really
want is a way to block a statement at a certain point - to say "block
after a snapshot is acquired" for example - and release that at a time
of my choosing.
...
Opinions? Is this some
On 8/19/13 7:23 PM, Sergey Konoplev wrote:
On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipov wrote:
>>Do you have some processes that intensively create tables or columns
>>and then delete them or create them in transaction and rollback the
>>transaction?
>>
>There are many processes that create
On 8/12/13 1:08 PM, Pavel Stehule wrote:
IF (bytes != LENGTH($1)) THEN
RAISE EXCEPTION 'Not all data copied to blob';
END IF;
PERFORM lo_close(fd);
FWIW, it's probably better to close before raising the exception...
--
Jim C. Nasby, Data Architect j...@nasby.
rebased
Regards
Pavel
2013/8/22 Peter Eisentraut
> 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 reba
On 08/21/2013 10:06 PM, Noah Misch wrote:
I concur, but our field experience doing it this way lessens my concern.
I see this change has hit master. I've pulled in the new patch for the
Fedora MinGW package.
Thanks,
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
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
On Wed, Aug 21, 2013 at 8:22 PM, Stephen Frost 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 Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
> Alexander Korotkov 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 ar
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. Remov
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 (pgsql-hacker
> 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 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 column
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:
http:/
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 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 (pgsql-hackers@pos
Andres Freund 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 favor o
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
*** a/doc/
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
where
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 i
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’:
setrefs.c
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 uninitiali
On Wed, Aug 21, 2013 at 10:47 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja 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
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]
bind_re
On Wed, Aug 21, 2013 at 4:05 AM, Andres Freund 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:
Merlin Moncure writes:
> On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja 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. Also psql
> directives for
On 2013-08-21 17:18, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja 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.
Fair enough
2013/8/21 Merlin Moncure
> On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja wrote:
> > On 8/21/13 5:05 PM, Merlin Moncure wrote:
> >>
> >> On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane wrote:
> >>>
> >>> Marko Tiikkaja writes:
>
> By default, PL/pgSQL does not print the error context of
On Aug 21, 2013, at 4:13 PM, Tom Lane 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 think David does
On Wed, Aug 21, 2013 at 10:07 AM, Marko Tiikkaja wrote:
> On 8/21/13 5:05 PM, Merlin Moncure wrote:
>>
>> On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane wrote:
>>>
>>> Marko Tiikkaja writes:
By default, PL/pgSQL does not print the error context of a RAISE
statement, for example:
>>>
>>
On 8/21/13 5:05 PM, Merlin Moncure wrote:
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane wrote:
Marko Tiikkaja 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 comp
On Wed, Aug 21, 2013 at 9:22 AM, Tom Lane wrote:
> Marko Tiikkaja 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 ver
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 set
Stephen Frost 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 back-patch
could cause
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
On 8/21/13 4:22 PM, Tom Lane wrote:
Marko Tiikkaja 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 y
Alexander Korotkov 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 get randomly dif
Marko Tiikkaja 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 inside a loop
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 v
2013/8/21 Marko Tiikkaja
> 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 $$
* 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:
> >
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
On Tue, Aug 20, 2013 at 8:53 PM, David E. Wheeler wrote:
> On Aug 20, 2013, at 6:50 PM, Tom Lane wrote:
>
> > You need more parentheses -- (source::text) would've worked.
>
> Alas, no, same problem as for CAST():
>
> ERROR: functions in index expression must be marked IMMUTABLE
>
> >> No probl
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund 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
> >>> -fno-aggressive-loop-optimizat
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 men
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 fr
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 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:
>>>
>>>
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, Ant
52 matches
Mail list logo
