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 build the documentation successfully.
best regards,
Florian Pflug
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
that schedule if we extended the cross-check, I think.
(I used REL9_4_STABLE as of today to try this, commit
1cf54b00ba2100083390223a8244430643c1ec07)
best regards,
Florian Pflug
fk-consistency2.spec
Description: Binary data
fk-consistency2.out
Description: Binary data
--
Sent via pgsql
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
On Oct24, 2014, at 19:32 , Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug f...@phlo.org 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 see
On Oct24, 2014, at 20:24 , Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug f...@phlo.org 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 tuple
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@postgresql.org)
To make changes to your subscription:
http
usefulness, this is a matter of
orthogonality. If we have named fields in anonymous record types, we should
provide a convenient way of specifying the field names.
So to summarize, I think this is an excellent idea, json_build_object
non-withstanding.
best regards,
Florian Pflug
--
Sent via
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.postgresql.org
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
Florian Pflug f...@phlo.org 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 go
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
to specify Disabled=true in a launchd plist and
use launchctl to enable the item.
Yup, macports also has Disabled=true in the launchd items they install.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
concurrent DELETES, but
not necessarily concurrent UPDATEs, even if such an UPDATE changes the parent
that a child row refers to.
Independent from whether the lock is actually desirable or not, that
inconsistency certainly looks like a bug to me...
best regards,
Florian Pflug
--
Sent via pgsql
,
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
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
started
implementing it.
Anyway, this is nice forward progress for 9.4, even if we get no further.
Yup! Thanks to everybody who made this happens!
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
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 wasn't happy with it at all, so that finally settled it.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
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 patch.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Apr11, 2014, at 19:42 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
On Apr10, 2014, at 02:13 , Florian Pflug f...@phlo.org wrote:
On Apr9, 2014, at 23:17 , Florian Pflug f...@phlo.org wrote:
On Apr9, 2014, at 21:35 , Tom Lane t...@sss.pgh.pa.us 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
into one. What do we do if we add those? Add yet a another set of
mergable transition functions? What about the various combinations
of invertible/non-invertible mergable/non-mergable that could result?
The opportunity cost seems pretty high here...
best regards,
Florian Pflug
--
Sent via pgsql
On Apr11, 2014, at 00:07 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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 64
On Apr11, 2014, at 01:30 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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 performance
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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
SUM_NONINV instead of SUM.
Then all we'd need would be an additional OID field that links the
invertible to the non-invertible definition.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Apr9, 2014, at 23:17 , Florian Pflug f...@phlo.org wrote:
On Apr9, 2014, at 21:35 , Tom Lane t...@sss.pgh.pa.us 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 it like
On Apr9, 2014, at 02:55 , David Rowley dgrowle...@gmail.com wrote:
On Wed, Apr 9, 2014 at 8:48 AM, Florian Pflug f...@phlo.org 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
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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org
), 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 AND
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.postgresql.org
been updated to
reflect the latest changes, so I think they need a little attention.
I'll see to updating the docs, and will post a final patch within the next
few days.
Dean, have you by chance looked at the other patches yet?
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing
On Mar5, 2014, at 23:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us 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
On Mar5, 2014, at 23:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Mar5, 2014, at 18:37 , Tom Lane t...@sss.pgh.pa.us 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
status is unknown) fits much better
than 1 (meaning program is dead and /var/run pid file exists). So *if*
we change it at all, we should change it to 4, not to some other, equally
arbitrary value.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Mar4, 2014, at 21:09 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 3 March 2014 23:00, Florian Pflug f...@phlo.org wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate-aggfwdtrans /
(inst-nloops * inst-ntuples
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 Mar5, 2014, at 18:27 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 5 March 2014 14:35, Florian Pflug f...@phlo.org 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
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
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 when such a facility
would be useful.
best regards,
Florian Pflug
--
Sent via
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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Feb27, 2014, at 17:56 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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's a feature, for much
On Feb24, 2014, at 17:50 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 20 February 2014 01:48, Florian Pflug f...@phlo.org wrote:
On Jan29, 2014, at 13:45 , Florian Pflug f...@phlo.org wrote:
In fact, I'm
currently leaning towards just forbidding non-strict forward transition
function
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-hackers@postgresql.org)
To make changes to your subscription
will probably do) followed
by j substring of the form $X$ (X is an arbitrary character).
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 Feb21, 2014, at 13:44 , John Williams jdwilliams1...@gmail.com 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
}
{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 rid of regex_flavor pre-9.1, I don't have an immediate
suspect...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Feb14, 2014, at 11:45 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-13 15:34:09 +0100, Florian Pflug wrote:
On Feb10, 2014, at 17:38 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-10 11:11:28 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So what
On Feb14, 2014, at 13:36 , Andres Freund and...@2ndquadrant.com 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
for a while...
Hm, true
On Feb14, 2014, at 14:07 , Andres Freund and...@2ndquadrant.com 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 branches, this stuff
On Feb14, 2014, at 16:32 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-14 10:26:07 -0500, Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Another idea for a fix would be to conflate lwWaiting and lwWaitLink into
one
field. We could replace lwWaiting by lwWaitLink != NULL
On Feb14, 2014, at 16:51 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-14 15:03:16 +0100, Florian Pflug wrote:
On Feb14, 2014, at 14:07 , Andres Freund and...@2ndquadrant.com wrote:
On 2014-02-14 13:52:45 +0100, Florian Pflug wrote:
I agree we should do that, but imo
On Feb14, 2014, at 19:21 , Andres Freund and...@2ndquadrant.com 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.
Currently
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 when doing that, we reset lwWaitLink
back to NULL anway.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers
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
first store updates lwWaitLink and the second lwWaiting. Thus, no reordering
seems to have taken place here...
best regards,
Florian Pflug
--
Sent via
On Jan29, 2014, at 09:59 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 28 January 2014 20:16, Florian Pflug f...@phlo.org wrote:
On Jan27, 2014, at 23:28 , Dean Rasheed dean.a.rash...@gmail.com wrote:
This case is explicitly forbidden, both in CREATE AGGREGATE and in the
executor. To me
in if we do
the latter, though.
The question is - is it worth it the effort to add that flag?
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
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
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 idea.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
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
--
Sent via pgsql-hackers mailing list
On Jan26, 2014, at 00:24 , David Rowley dgrowle...@gmail.com wrote:
On Sat, Jan 25, 2014 at 3:21 PM, Florian Pflug f...@phlo.org wrote:
On Jan24, 2014, at 08:47 , Dean Rasheed dean.a.rash...@gmail.com wrote:
The invtrans_minmax patch doesn't contain any patches yet - David, could
you provide
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 created by other tests?
best regards,
Florian Pflug
--
Sent
On Jan25, 2014, at 09:50 , David Rowley dgrowle...@gmail.com wrote:
On Thu, Jan 23, 2014 at 1:57 PM, Florian Pflug f...@phlo.org wrote:
On Jan23, 2014, at 01:17 , David Rowley dgrowle...@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug f...@phlo.org wrote:
If you want to play
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
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 regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
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 via pgsql-hackers
On Jan23, 2014, at 17:20 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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 did consider
On Jan23, 2014, at 01:17 , David Rowley dgrowle...@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug f...@phlo.org 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
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:07 , David Rowley dgrowle...@gmail.com wrote:
On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug f...@phlo.org wrote:
On Jan20, 2014, at 08:42 , David Rowley dgrowle...@gmail.com wrote:
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug f...@phlo.org wrote:
* I've also renamed
not have unbounded following.
I don't think adding yet another type of aggregation function is the
solution here.
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
On Jan20, 2014, at 15:20 , Florian Pflug f...@phlo.org 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 functions assume
.
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 functions AFAIR.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql
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
On Jan20, 2014, at 08:42 , David Rowley dgrowle...@gmail.com wrote:
On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug f...@phlo.org 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
the new
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 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 regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql
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
On Jan18, 2014, at 06:15 , David Rowley dgrowle...@gmail.com wrote:
On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug f...@phlo.org wrote:
On Jan17, 2014, at 23:34 , David Rowley dgrowle...@gmail.com wrote:
The test turned out to become:
if (state-expectedScale == -1)
state
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
On Jan17, 2014, at 20:34 , David Rowley dgrowle...@gmail.com wrote:
On Fri, Jan 17, 2014 at 3:05 PM, Florian Pflug f...@phlo.org 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 transition
, 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 Jan16, 2014, at 09:07 , David Rowley dgrowle...@gmail.com wrote:
On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug f...@phlo.org 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
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 f...@phlo.org wrote:
On Jan16, 2014, at 09:07 , David Rowley dgrowle...@gmail.com wrote:
On Wed, Jan 15, 2014 at 5:39 AM, Florian Pflug f...@phlo.org
On Jan15, 2014, at 10:08 , Marko Tiikkaja ma...@joh.to wrote:
On 1/15/14 7:07 AM, Florian Pflug wrote:
On Jan15, 2014, at 01:34 , Marko Tiikkaja ma...@joh.to wrote:
It's me again, trying to find a solution to the most common mistakes I
make. This time it's accidental shadowing of variables
On Jan15, 2014, at 11:20 , Pavel Stehule pavel.steh...@gmail.com wrote:
2014/1/15 Marko Tiikkaja ma...@joh.to
On 1/15/14 7:07 AM, Florian Pflug wrote:
On Jan15, 2014, at 01:34 , Marko Tiikkaja ma...@joh.to wrote:
It's me again, trying to find a solution to the most common mistakes I make
On Jan15, 2014, at 13:08 , Pavel Stehule pavel.steh...@gmail.com wrote:
2014/1/15 Florian Pflug f...@phlo.org
On Jan15, 2014, at 11:20 , Pavel Stehule pavel.steh...@gmail.com wrote:
2014/1/15 Marko Tiikkaja ma...@joh.to
plpgsql.warnings = 'all' # enable all warnings, defauls to the empty
On Jan15, 2014, at 13:32 , Marko Tiikkaja ma...@joh.to 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 during execution
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 list (pgsql-hackers
On Jan14, 2014, at 17:39 , Florian Pflug f...@phlo.org wrote:
On Jan14, 2014, at 11:06 , David Rowley dgrowle...@gmail.com 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
On Jan16, 2014, at 02:32 , Florian Pflug f...@phlo.org wrote:
On Jan14, 2014, at 17:39 , Florian Pflug f...@phlo.org wrote:
On Jan14, 2014, at 11:06 , David Rowley dgrowle...@gmail.com wrote:
Here's a patch which removes sum(numeric) and changes the documents a
little to remove a reference
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
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
, btw - the database provides the building
blocks, i.e. PREPARE and COMMIT, and leaves it to a transaction manager
to deal with issues that require a whole-cluster perspective.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
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
(Responding to both of your mails here)
On Jan14, 2014, at 01:20 , Jim Nasby j...@nasby.net 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
rows
but INSERT/UPDATE/DELETE
) 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
of 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-hackers
1 - 100 of 757 matches
Mail list logo
