de
---> Dependencies to be installed: opensp
BTW, why does the list of suggested packages include docbook-xml? I was
under the impression that postgres used only the SGML version of docbook.
And I previously only has the SGML version installed, and I'm pretty sure
that I was able to b
ge a FORCEd value, unless
they are called by a super-user, or are marked SECURITY DEFINER and owned by
a super-user.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ASCADE instead of RESTRICT. So even a full UPDATE or DELETE
of the child rows doesn't help.
But maybe I miss-understood what you proposed.
best regards,
Florian Pflug
fk-consistency2.spec
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Oct24, 2014, at 20:24 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug wrote:
>>> What about doing one scan using SnapshotAny and then testing each
>>> returned row for visibility under both relevant snapshots? See
>>> whether there is any
On Oct24, 2014, at 19:32 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug wrote:
>> The only other option I see would be so teach the executor to check
>> whether *any* snapshot between the transaction's snapshot and a current
>> snapshot would s
that I'd but the burden on the session
that attempts to remove a parent row, instead of on the sessions which
add or remove children.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e corresponding out-file which shows that SSI permits the concurrent
schedule. Since SSI doesn't concern itself with RI enforcement queries,
it would also permit that schedule if we extended the cross-check, I think.
(I used REL9_4_STABLE as of today to try this, commit
1cf54b00ba2100083
e of doing that over fixing the crosscheck logic would be
that it'd make it possible to write concurrency-safe FK triggers in any
procedural language.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aker lock level with SELECT FOR
NO KEY UPDATE.
The attached patch updated README.tuplock accordingly.
best regards,
Florian Pflug
README.tuplock.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
why we want another mechanism unless it's needed in some
> other context.
I've wanted to name the field of rows created with ROW() on more than
one occasion, quite independent from whether the resulting row is converted
to JSON or not. And quite apart from usefulness, this is a matte
PK constraint is broken. I don't think that's acceptable in any isolation
level.
Best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Florian Pflug wrote:
> So in conclusion, the lock avoids raising constraint violation errors in
> a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts some
> constraint violation errors into serialization failures. Or at least that's
> how it looks to me.
I
- but as you say, that set doesn't necessarily the set of columns in the
FK constraint at all.
So currently, it seems that the lock only prevent concurrent DELETES, but
not necessarily concurrent UPDATEs, even if such an UPDATE changes the parent
that a child row refers to.
Independent from
.
>>
>> It’s the default. When you run `launchctl load -w` it overrides it to false
>> in
>> its database. I’m fine to have it be less opaque, though.
>
> Yes, AFAICT it’s conventional to specify Disabled=true in a launchd plist and
> use launchctl to enable the item.
p name, whereas a quoted "+" would simply become part of
the user name (or group name, if there's an additional unquoted
"+" before it).
So +foo would refer to the group , +"FOO" to the group ,
and +"+A" to the group <+A>.
I haven't checked if such an approach would be sufficiently
backwards-compatible, though.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that, PL/pgSQL is about as appealing as BASIC
as a programming language...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
which exercises
the non-strict case, which seemed like a bad idea. For the string case -
I didn't expect that to turn out to be *quite* this messy when I started
implementing it.
> Anyway, this is nice forward progress for 9.4, even if we get no further.
Yup! Thanks to everybody
On Apr11, 2014, at 19:42 , Tom Lane wrote:
> Florian Pflug writes:
>> Yes, the idea had come up at some point during the review discussion. I
>> agree that it's only worthwhile if it works for state type internal - though
>> I think there ought to be a way to allow
meter.
What I like about the initfunc idea is that it also naturally extends to
ordered-set aggregates, I think it'd be very useful for some possible
ordered-set aggregates to received their direct arguments beforehand and not
afterwards.
But that all seems largely orthogonal to the invtrans
the NULL handling of some aggregates was
broken otherwise, and it seemed simpler to fix this in one place than going
over all the aggregates separately. OTOH, when I wrote the docs, I noticed
how hard it was to describe the behaviour accurately, which made me like it
less and less. And Dean was
On Apr11, 2014, at 01:30 , Tom Lane wrote:
> Florian Pflug writes:
>> As for evidence - have you looked at the patch I posted? I'd be very
>> interested to know if it removes the performance differences you saw.
>
> (1) You can't really prove the absence of a perf
On Apr11, 2014, at 00:07 , Tom Lane wrote:
> Florian Pflug writes:
>> I still think you're getting ahead of yourselves here. The number of
>> aggregates which benefit from this is tiny SUM(int2,int4) and maybe
>> BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on
ctions might not be the last kind of transition functions we ever
add. For example, if we ever get ROLLUP/CUBE, we might want to have
a mergefunc which takes two aggregation states and combines them
into one. What do we do if we add those? Add yet a another set of
"mergable" transition
On Apr10, 2014, at 02:13 , Florian Pflug wrote:
> On Apr9, 2014, at 23:17 , Florian Pflug wrote:
>> On Apr9, 2014, at 21:35 , Tom Lane wrote:
>>> A quick test says that avg(int4)
>>> is about five percent slower than sum(int4), so that's the kind of hit
&g
On Apr9, 2014, at 23:17 , Florian Pflug wrote:
> On Apr9, 2014, at 21:35 , Tom Lane wrote:
>> A quick test says that avg(int4)
>> is about five percent slower than sum(int4), so that's the kind of hit
>> we'd be taking on non-windowed aggregations if we do i
need to remove entries from the aggregation state. That would also
allow the users to *force* the non-invertible aggregate to be used by
simply saying "SUM_NONINV" instead of "SUM".
Then all we'd need would be an additional OID field that links the
invertible to
not-very-complex
function, though...
I'll go and check the disassembly - maybe something in int4_avg_accum turns
out to be more complex than is immediately obvious. I'll also try to create
a call profile, unless you already have one from your test runs.
best regards,
Florian Pflug
--
Sent v
On Apr9, 2014, at 02:55 , David Rowley wrote:
> On Wed, Apr 9, 2014 at 8:48 AM, Florian Pflug wrote:
>
> As explain above, invtrans_bool is a bit problematic, since it carries
> a real risk of performance regressions. It's included for completeness'
> sake, and should
.
I don't really expect all the add-on patches to make it into 9.4 -
they don't seem to have gotten much attention yet - but at least
the inverse transition functions for the basic arithmetic aggregates
should be doable I hope.
best regards,
Florian Pflug
--
Sent via pgsq
ompared do applying what
we have now, and optimizing in 9.5 further.
best regards,
Florian Pflug
PS: Sorry for the broken mail I sent earlier - miss-touched on my Phone ;-(
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
>> ), which seem reasonable. But
> then I started testing performance, and I found cases where the
> improvement is not nearly what I expected.
>
> The example cited at the start of this thread is indeed orders of
> magnitude faster than HEAD:
>
> SELECT SUM(n::int) OVER (ROWS BETWEEN CURRENT ROW
6fd9-64d1-40b9-8861-e61820292...@phlo.org
>> all of the other patches are unchanged so it's save to use Florian's latest
>> ones
>>
>> Perhaps Dean can confirm that there's nothing else outstanding?
>>
>
> Florian mentioned upthread that the doc
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday use
On Mar5, 2014, at 23:49 , Tom Lane wrote:
> Florian Pflug writes:
>> On Mar5, 2014, at 18:37 , Tom Lane wrote:
>>> My advice is to lose the EXPLAIN output entirely. If the authors of
>>> the patch can't agree on what it means, what hope have everyday use
ak things, so why do it if there's no clear benefit?
In the EPERM case (or, rather the non-ENOENT case), I agree with Amit
that "4" (meaning "program or service status is unknown") fits much better
than "1" (meaning "program is dead and /var/run pid file exists&quo
On Mar5, 2014, at 18:27 , Dean Rasheed wrote:
> On 5 March 2014 14:35, Florian Pflug wrote:
>> When I added the EXPLAIN stuff, I initially simply reported the number
>> of times nodeWindowAgg has to restart the aggregation. The problem with
>> that approach is that not a
formance characteristics depends on the input data,
so we IMHO need some way for users to check what's actually happening.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
> On 3 March 2014 23:00, Florian Pflug wrote:
>>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>>
>>> double tperrow = winaggstate->aggfwdtrans /
>>> (inst->nlo
SPLITTER my_xml_splitter;
As far as I can tell, the idea is to allow a datatype to influence how
it's split into chunks for TOASTing so that functions can fetch only
the required slices more easily. To judge whether that is worthwhile or
not, you'd have to provide a concrete example of
t least version
x.y before inet_gist can be installed". That would avoid failing with a rather
cryptic error later.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb27, 2014, at 17:56 , Tom Lane wrote:
> Florian Pflug writes:
>> Maybe I'm missing something, but isn't the gist of the problem here that
>> pg_dump won't explicitly state the operator class if it's the default?
>
> That's not a bug, it'
If so, can't we just make pg_dump always spell out the operator class
explicitly? Then changing the default will never change the meaning of
database dumps, so upgraded clusters will simply continue to use the
old (now non-default) opclass, no?
best regards,
Florian Pflug
--
Sent via pgs
On Feb24, 2014, at 17:50 , Dean Rasheed wrote:
> On 20 February 2014 01:48, Florian Pflug wrote:
>> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>>> In fact, I'm
>>> currently leaning towards just forbidding non-strict forward transition
>>> function
27;]*|'')*'|(\$[^$]*\$).*\2)+)$REG$, 'g');
regexp_matches
-
{" ",NULL}
{a,NULL}
{b,NULL}
{c,NULL}
{d,NULL}
{e,NULL}
{f,NULL}
{g,NULL}
{h,NULL}
{i,NULL}
{j,NULL}
(11 rows)
Time: 4787.239 ms
Aha! Since we go
On Feb21, 2014, at 13:44 , John Williams wrote:
> I'm writing a pgsql extension in C, which is multithreaded. The SPI
> connection is global, so do I have to implement a lock to make sql
> queries in each thread, or can I make a connection on a per-thread basis?
Postgres backends aren't multi-thr
EG$((?:[^'"$;]+|"[^"]*"|'(?:[^']*|'')*'|(\$[^$]*\$).*\2)+)$REG$, 'g');
Time: 696.137 ms
postgres=# select regexp_matches(' $a$b$c$d$e$f$g$h$i$',
$REG$((?:[^'"$;]+|"[^"]*"|'(?:[^']
's a patch in the current
CF, I believe, which adds support for inheritance to foreign tables, so all
you'd
have to do is to make the foreign table's inheritance structure match the remote
table's.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-
On Feb14, 2014, at 19:21 , Andres Freund wrote:
> On 2014-02-14 18:49:33 +0100, Florian Pflug wrote:
>> Well, the assumption isn't all that new. We already have the situation that
>> a PGPROC may be not on any wait queue, yet its lwWaitLink may be non-NULL.
>> Currentl
On Feb14, 2014, at 16:51 , Andres Freund wrote:
> On 2014-02-14 15:03:16 +0100, Florian Pflug wrote:
>> On Feb14, 2014, at 14:07 , Andres Freund wrote:
>>> On 2014-02-14 13:52:45 +0100, Florian Pflug wrote:
>>>>> I agree we should do that, but imo not in the
On Feb14, 2014, at 16:32 , Andres Freund wrote:
> On 2014-02-14 10:26:07 -0500, Tom Lane wrote:
>> Florian Pflug writes:
>>> Another idea for a fix would be to conflate lwWaiting and lwWaitLink into
>>> one
>>> field. We could replace "lwWaiting
On Feb14, 2014, at 14:07 , Andres Freund wrote:
> On 2014-02-14 13:52:45 +0100, Florian Pflug wrote:
>>> I agree we should do that, but imo not in the backbranches. Anything
>>> more than than the minimal fix in that code should be avoided in the
>>> stable b
On Feb14, 2014, at 13:36 , Andres Freund wrote:
> On 2014-02-14 13:28:47 +0100, Florian Pflug wrote:
>>> I don't think that can actually happen because the head of the wait list
>>> isn't the lock holder's lwWaitLink, but LWLock->head. I thought the same
On Feb14, 2014, at 11:45 , Andres Freund wrote:
> On 2014-02-13 15:34:09 +0100, Florian Pflug wrote:
>> On Feb10, 2014, at 17:38 , Andres Freund wrote:
>>> On 2014-02-10 11:11:28 -0500, Tom Lane wrote:
>>>> Andres Freund writes:
>>>>> So what we nee
ind it to block indefinitely.
I wonder whether LWLockRelease really needs to update lwWaitLink at all.
We take the backends we awake off the queue by updating the queue's head and
tail, so the contents of lwWaitLink should only matter once the backend is
re-inserted into some wait queue. But w
0x10(%rcx),%rdi
0x00647f4b : movq $0x0,0x48(%rcx)
0x00647f53 : movb $0x0,0x41(%rcx)
0x00647f57 : callq 0x606210
I haven't checked the offsets, but since lwWaitLink is an 8-byte quantity
and lwWaiting a single-byte quantity, it's pretty much certain that the
fi
On Jan29, 2014, at 09:59 , Dean Rasheed wrote:
> On 28 January 2014 20:16, Florian Pflug wrote:
>> On Jan27, 2014, at 23:28 , Dean Rasheed wrote:
>>> This case is explicitly forbidden, both in CREATE AGGREGATE and in the
>>> executor. To me, that seems overly re
the connection" if it responds to a SYN packet with RST...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
simply do what
normal functions calls do and pretend they return NULL for NULL inputs.
Not sure how the rule that forward transition functions may not return
NULL if there's an inverse transition function would fit in if we do
the latter, though.
The question is - is it worth it the effort
with" for want of a
> better name. And with it I can do:
>
> $ make check-with TESTS="json jsonb"
>
> and have it do the temp install etc and then run just those two tests.
+1 for the feature (+Inf, actually), but will this work if the tests
depend on stuff crea
On Jan26, 2014, at 00:24 , David Rowley wrote:
>> On Sat, Jan 25, 2014 at 3:21 PM, Florian Pflug wrote:
>> On Jan24, 2014, at 08:47 , Dean Rasheed wrote:
>> The invtrans_minmax patch doesn't contain any patches yet - David, could
>> you provide some for these fun
gt; even knows that is being proposed and would likely cause more
> discussion if they did. So I wish to push back the # syntax to a later
> release when it has had more discussion. It would be good if you could
> lead that discussion in later releases.
+1
best regards,
Florian Pflug
aranteed by the C standard - it says overflows of signed integral types
produce undefined results. We currently depend on wrapping semantics for
these types in more places, and therefore need GCC's "-fwrapv" anway, but
I still wonder if adding more of these kinds of checks is a good ide
On Jan25, 2014, at 09:50 , David Rowley wrote:
> On Thu, Jan 23, 2014 at 1:57 PM, Florian Pflug wrote:
>> On Jan23, 2014, at 01:17 , David Rowley wrote:
>> > On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> >> If you want to play with
>> >>
like
ALTER SYSTEM SET synchronous_commit='local';
Doing that seems unlikely to meet much resistant on grounds of principle,
so it seems to me that working on that would be the best way forward for
the submitter. I don't know how hard it would be to pull this off,
though.
best
t can be applied to so many aggregates, but let's not try to do
> it all at once.
Working on that now, will post individual patches later today.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jan23, 2014, at 17:20 , Tom Lane wrote:
> Florian Pflug writes:
>> Is there a particular reason why the "direct" arguments of ordered-set
>> aggregates are not passed to the transition function too?
>
> Because they have to be evaluated only once.
>
> I
number of rows
smaller than the hypothetical row, AFAICS.
Another example (that we don't currently provide, but still) would be a
histogram aggregate which receives an array of buckets as direct args and
returns a similarly shaped array of counters.
best regards,
Florian Pflug
--
Sent vi
On Jan23, 2014, at 01:07 , David Rowley wrote:
> On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote:
>> On Jan20, 2014, at 08:42 , David Rowley wrote:
>> >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> >> * I've also renamed INVFUNC to INV
;s final function doesn't take an
argument of type anyelement, even though it returns anyarray.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jan23, 2014, at 01:17 , David Rowley wrote:
> On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote:
>> If you want to play with
>> this, I think the first step has to be to find a set of guarantees that
>> SUM(float) is supposed to meet. Currently, SUM(float) g
th GCC's desire to check format strings.
>
> That last is a deal-breaker. It's not just whether "gcc desires" to check
> this --- we *need* that checking, because people get it wrong without it.
There's an attribute that enables this check for arbitrary func
On Jan20, 2014, at 15:20 , Florian Pflug wrote:
> * In CREATE AGGREGATE, we should state the precise axioms we assume about
> forward
> and inverse transition functions. The last time I read the text there, it was
> a bit ambiguous about whether inverse transition func
allowing aggregates to have 2 forward transition functions and if the 2nd
> one exists then it could be used in windowing functions where the frame
> does not have "unbounded following".
I don't think adding yet another type of aggregation function is the
solution here.
be
ular warning then we
ought not warn about it anyway, I guess, because that would indicate that there
are genuine reasons for doing whatever it is the warning complains about.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jan20, 2014, at 08:42 , David Rowley wrote:
>> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote:
>> * An assert that the frame end doesn't move backwards - I realized that
>> it is after all easy to do that, if it's done after the loop which adds
>
that tomorrow. Otherwise, things look good as far as I'm concerned.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to
do that tomorrow. Otherwise, things look good as far as I'm concerned.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ows=1 loops=1)
-> Index Only Scan using boolvals_v_idx on boolvals
(cost=0.29..474.41 rows=9950 width=1) (actual time=0.061..0.061 rows=1 loops=1)
Index Cond: (v IS NOT NULL)
Heap Fetches: 1
Total runtime: 0.100 ms
which looks fine, no?
best
On Jan18, 2014, at 06:15 , David Rowley wrote:
>> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote:
>> On Jan17, 2014, at 23:34 , David Rowley wrote:
>>> The test turned out to become:
>>> if (state->expectedScale == -1)
>>> stat
in the
regression tests which simply concatenates all the calls into a string, e.g.
you might get "F:1 F:2 F:3 I:1" if we aggregated 1,2,3 and then removed 1.
I think that should be possible with an SQL-language forward and inverse
transfer function, but I haven't tried. I can try, if you want.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jan17, 2014, at 20:34 , David Rowley wrote:
> On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug wrote:
>
>> I've now shuffled things around so that we can use inverse transition
>> functions
>> even if only some aggregates provide them, and to allow inverse trans
floating around. Could you push your latest version?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I had some more fun with this, the result is v2.5 of the patch (attached).
Changes are explained below.
On Jan16, 2014, at 19:10 , Florian Pflug wrote:
> On Jan16, 2014, at 09:07 , David Rowley wrote:
>> On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug wrote:
>>> The notn
On Jan16, 2014, at 09:07 , David Rowley wrote:
> On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug wrote:
>> The notnullcount machinery seems to apply to both STRICT and non-STRICT
>> transfer function pairs. Shouldn't that be constrained to STRICT transfer
>> function p
On Jan16, 2014, at 02:32 , Florian Pflug wrote:
> On Jan14, 2014, at 17:39 , Florian Pflug wrote:
>> On Jan14, 2014, at 11:06 , David Rowley wrote:
>>> Here's a patch which removes sum(numeric) and changes the documents a
>>> little to remove a reference to usin
On Jan14, 2014, at 17:39 , Florian Pflug wrote:
> On Jan14, 2014, at 11:06 , David Rowley wrote:
>> Here's a patch which removes sum(numeric) and changes the documents a little
>> to remove a reference to using sum(numeric) to workaround the fact that
>> there's
outside of the frame. Which, I guess,
is a box that best stays closed...
I'm currently thinking the best way forward is to get a basic patch
without any NUMERIC stuff committed, and to revisit this after that's done.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing lis
On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote:
> On 1/15/14 1:23 PM, Florian Pflug wrote:
>> The fact that it's named plpgsql.warnings already clearly documents that
>> this only affects plpgsql. But whether a particular warning is emitted
>> during compilation or d
On Jan15, 2014, at 13:08 , Pavel Stehule wrote:
> 2014/1/15 Florian Pflug
>> On Jan15, 2014, at 11:20 , Pavel Stehule wrote:
>> > 2014/1/15 Marko Tiikkaja
>> > plpgsql.warnings = 'all' # enable all warnings, defauls to the empty
>> > list, i.e.
On Jan15, 2014, at 11:20 , Pavel Stehule wrote:
> 2014/1/15 Marko Tiikkaja
> On 1/15/14 7:07 AM, Florian Pflug wrote:
> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote:
> It's me again, trying to find a solution to the most common mistakes I make.
> This time it'
On Jan15, 2014, at 10:08 , Marko Tiikkaja wrote:
> On 1/15/14 7:07 AM, Florian Pflug wrote:
>> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote:
>>> It's me again, trying to find a solution to the most common mistakes I
>>> make. This time it's accident
enable. I'm sure you'll
come up with more unsafe coding practices to warn about in the future - for
example, consistent_into immediately comes to mind ;-)
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
's peers, I think we'd use the inverse transfer
function to fully un-add the old frame, and then add back the new frame.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pe(myarray, NULL);
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
dimensions is actually worse than
the lower-bound problem. So *if* we ever remove support for arbitrary
lower bounds, we should also add distinct types for different dimensions.
That'd probably required some extension of the type system though...
best regards,
Florian Pflug
--
Sent via pgsql-
t does without performing
> inverse
> transitions. Personally I'd rather focus on trying to get SUM(numeric) in
> there
> for 9.4
I think it'd be worthwile to get this into 9.4, if that's still an option,
even if we only support COUNT.
best regards,
Florian Pflug
--
(Responding to both of your mails here)
On Jan14, 2014, at 01:20 , Jim Nasby wrote:
> On 1/13/14, 5:57 PM, Josh Berkus wrote:
>> On 01/13/2014 03:41 PM, Florian Pflug wrote:
>>> It therefor isn't an oversight that SELECT ... INTO allows multiple result
>>> r
s release
changes the behaviour of one of the procedural languages, we'd increment
that language's version, and enable the old behaviour for all functions
tagged with an older one.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g ourselves by changing that later -
not, at least, unless we have a *very* good reason for it. Which, AFAICS, we
don't.
(And yeah, personally I'd prefer if we'd complain about multiple rows. But it's
IMHO just too late for that)
best regards,
Florian Pflug
--
system. But rolling
back the transaction is nevertheless *impossible* at that point (except by
PITR, and hence the quoted around reciver). So the only alternative to
"recovering" them, i.e. have them abort their waiting, is to let them linger
indefinitely, still holding their locks, preventing xmin from advancing, etc,
until either the client disconnects or the server is restarted.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 759 matches
Mail list logo
