--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
get the correct one.
Regards,
Andreas Karlsson
On Fri, 2010-12-17 at 21:00 -0500, Robert Haas wrote:
On Fri, Dec 17, 2010 at 8:34 PM, andreas andr...@proxel.se wrote:
It has annoys me every time I want to move a table to another schema
that it completes to SET SCHEMA TO DEFAULT after a couple
On Fri, 2010-12-17 at 21:20 -0500, Robert Haas wrote:
On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson andr...@proxel.se wrote:
What it does is gets rid of the incorrect completion which comes from
the completion rule for SET foo TO bar by adding the correct
completion for SET SCHEMA
Sorry, everyone.
Ignore my patch. This was already fixed in HEAD and while I wrote my
patch for the HEAD I somehow failed to spot that it was already fixed
when testing without my patch.
Nice that is fixed, and sorry for the noise.
Andreas
--
Sent via pgsql-hackers mailing list
to advance_aggregates in nodeAgg.c
*/
static void
advance_windowaggregate(WindowAggState *winstate,
Regards,
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
---+-
{10608,10612} | {1009,1015}
(1 row)
Regards,
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here is a patch, but I am not sure I am not sure if I like my idea for
format. What do you think?
SELECT pg_describe_object('pg_amproc'::regclass,oid,0)
FROM pg_amproc WHERE oid IN (10608,10612);
pg_describe_object
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Joel Jacobson discovered a bug in the function pg_describe_object where
it does not produce unique identifiers for some entries in pg_amproc.
This patch fixes the bug where when two entries in
On Tue, 2011-01-11 at 11:43 -0500, Tom Lane wrote:
If that's what you're after, getObjectDescription is entirely
unsuitable, because of the fact that its results are dependent
on search path and language settings.
regards, tom lane
Agreed, and as long as the additional
On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
It really shouldn't be useful to include those. Attend what it says in
the fine manual for CREATE OPERATOR CLASS:
In a FUNCTION clause, the operand data type(s) the function is
intended to support, if different from the input
Here is a very simple change of the patch to make the output look more
like the syntax of ALTER OPERATOR FAMILY to improve consistency.
Before patch:
function 1 bttextcmp(text,text) of operator family array_ops for access method
gin
With the first version:
function 1 bttextcmp(text,text) of
Hi Josh,
Here is my review of this patch for the commitfest.
Review of https://commitfest.postgresql.org/action/patch_view?id=439
Contents and Purpose
This patch adds the \dL command in psql to list the procedual languages.
To me this seems like a useful addition to the
On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
But I can read the handwriting on the wall: if I want this done right,
I'm going to have to do it myself.
regards, tom lane
Do I understand you correctly if I interpret what you would like to see
is the same format used
On Mon, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
Yeah. Procedural langauges may strictly be wrong, but people aren't
likely to misunderstand it.
That was idea when suggesting we call it procedural languages. It is
short and I do not think it can be misunderstood.
Regards,
Andreas
On Sun, 2011-01-16 at 22:32 -0500, Josh Kupershmidt wrote:
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson andr...@proxel.se wrote:
Should we include a column in \dL+ for the laninline function (DO
blocks)?
Hrm, I guess that could be useful for the verbose output at least.
Magnus
On Sun, 2011-01-16 at 14:28 -0500, Tom Lane wrote:
One other point here is that I find messages like this a mite
unreadable:
function 1 (oidvector[], oidvector[]) btoidvectorcmp(oidvector,oidvector) of
operator family array_ops for access method gin
If we were to go with this, I'd be
Hi Josh,
Nope, I do not have any better ideas than DO Blocks?.
Everything looks good with the exception one bug now.
\dL foo
* QUERY **
SELECT l.lanname AS Name,
pg_catalog.pg_get_userbyid(l.lanowner) as Owner,
l.lanpltrusted AS Trusted
FROM pg_catalog.pg_language
On Tue, 2011-01-18 at 19:34 -0500, Josh Kupershmidt wrote:
Got that now too. I lost my ~/.emacs file recently, which is mostly
why I'm making whitespace mistakes. Rebuilding slowly though;
(setq-default show-trailing-whitespace t) is what I needed.
Aha, I see.
I left the Call Handler and
On Fri, 2011-01-21 at 11:00 -0500, Garick Hamlin wrote:
I can't tell if PG supports querying a secondary RADIUS server?
I don't see how I would do it with the syntax here ...
http://developer.postgresql.org/pgdocs/postgres/auth-methods.html
Are multiple servers not supported?
Garick
that data twice it sounds like
it should.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(while EXECUTE foo(1); is) and I did not feel the extra lines
of code to add a query to check if the number of expected parameters is
greater than 0 were worth it.
--
Andreas Karlsson
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 4f7df36..15bb8c1
sanity, I should have done so
myself when I noticed the problem.
A new version is attached.
Best regards,
Andreas
--
Andreas Karlsson
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index abf9bc7..ee63198
*** a/src/bin/psql/tab-complete.c
--- b/src
be found at:
https://github.com/depesz/Pg--Explain
Best regards,
Andreas
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2011-11-10 23:42, Andreas Karlsson wrote:
Hi,
I recommend using the XML, JSON or YAML version of the plan, whichever
is easiest in your programming language to parse. I do not think anyone
has written a formal schema yet for the XML but it still should be much
easier to parse than rolling
was sent to those who should be
reminded instead to the list. My personal experience is that personal
reminders are more effective than public naming and shaming.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
which currently
seems to be larger than PL/Perl, PL/Python and PL/tcl. Including having
the possibility to implement window functions.
http://pgxn.org/dist/plv8/doc/plv8.html#Window.function.API
Nice job with PL/Lua,
Andreas
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql
.
There shouldn't be any major problems with implementing LISTEN on the
slaves since LISTEN is done in memory.
I feel like I as a beginner to the codebase am missing something bit
because while this is a fair bit of work it does not too hard to implement.
Andreas
--
Andreas Karlsson
--
Sent
/wiki/Table_partitioning#Active_Work_In_Progress
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
--
Andreas Karlsson
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
new file mode 100644
index dea5195..fb9c41a
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
***
*** 137,142
--- 137,148
/row
row
+entrytypejson/type
On 11/25/2013 11:52 PM, Merlin Moncure wrote:
On Mon, Nov 25, 2013 at 3:07 PM, Andreas Karlsson andr...@proxel.se wrote:
Hi,
When looking at table 8-1 at
http://www.postgresql.org/docs/9.3/static/datatype.html i noticed that all
types except for json was in alphabetical order. I have attached
/ca+tgmobzhfrjnyz-fyw5kdtrurk0hjwp0vtp5fgzle6evsw...@mail.gmail.com
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/29/2013 09:54 AM, Antonin Houska wrote:
On 11/29/2013 01:13 AM, Andreas Karlsson wrote:
When doing partial matching the code need to be able to return the union
of all TIDs in all the matching posting trees in TID order (to be able
to do AND and OR operations with multiple search keys
that a TIDBitmap based on
the fast update pending list always will fit in the memory. That does
not sound like a good assumption to me.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
/d9250da032e723d80bb0150b9276cc544df6a087/src/backend/access/heap/README.tuplock#L68
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/09/2013 08:05 PM, hubert depesz lubaczewski wrote:
Thanks. Read that. Still, it would be good to have some information in
normal docs, but I guess this has to do for now.
It is mentioned several times in the documentation but I do not think it
is explained anywhere.
--
Andreas
you considered?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with an increased
chance of spilling to disk.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
loops=1)
Index Cond: (oid = s.datid)
Planning time: 0.264 ms
Total runtime: 0.158 ms
(11 rows)
Links
1.
http://www.postgresql.org/message-id/cacfv+pknembqyjpcqrgsvmc_hvrgai3d_ge893n8qbx+ymh...@mail.gmail.com
--
Andreas Karlsson
diff --git a/src/backend/commands/explain.c b/src/backend
guess one would have to modify psql_scan() to check if a scanned query
only contains comments and then not send it to the server at all.
The minimal file to reproduce it is:
/**/
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
the improvements to joins.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
:
PQexec(..., /**/;);
PQexec(..., /**/);
If this has to be fixed it should be in the client. I think people would
complain if we broke the API by starting to throw an exception on PQexec
with a string containing no actual query.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql
On 12/24/2013 03:33 AM, Tom Lane wrote:
Andreas Karlsson andr...@proxel.se writes:
The patch does not include any changes to documentation or tests. I will
fix that if people think this patch is useful.
I take it you've not tried the regression tests with this.
Yeah, forgot to mention
thought the server
should print timing even if PGRES_EMPTY_QUERY is returned. Now after
thinking on it I am not so sure.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/24/2013 02:31 PM, Peter Eisentraut wrote:
On 12/23/13, 8:12 PM, Andreas Karlsson wrote:
A user asked in -performance[1] if there is a way to measure the
planning time.
log_planner_stats
Thanks for the suggestion, I will use that if I need to know the plan
times. But I do not think
not
clutter anything too much.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. This tidbitmap becomes lossy if
the matching TIDs do not fit into the workmem.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
New version of the patch with updated documentation and which does not
display the planning time when the COSTS are off.
I will add it to the next commitfest.
--
Andreas Karlsson
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
new file mode 100644
index 2af1738..240a3d5
for
improvement. You could decrement the bound for the tuplesort after every
completed sort. Otherwise the optimizations for small limits wont apply
to partial sort.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
of the patch.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
feel that such a patch
would be more invasive.
Just my reasoning for the current solution. I welcome any opinions about
how to print planning time for prepared statements since I am not a
heavy user of them.
--
Andreas Karlsson
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
-SQL-assertions-prototype.patch.
Best regards,
Andreas
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
example
how this would look compared to your RETURNING REJECTS proposal?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
when you feel it
is ready for a review.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/12/2014 11:20 PM, Peter Geoghegan wrote:
On Sun, Jan 12, 2014 at 8:12 AM, Andreas Karlsson andr...@proxel.se wrote:
On 01/11/2014 11:42 PM, Peter Geoghegan wrote:
I recently suggested that rather than RETURNING REJECTS, we could have
a REJECTING clause, which would see a DML statement
. If the consensus
is that we want to always measure it I will look at implementing that
instead.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
functions. They are named things like
tsmatchsel, tsmatchjoinsel, and rangesel.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/18/2014 08:13 PM, Jeremy Harris wrote:
On 31/12/13 01:41, Andreas Karlsson wrote:
On 12/29/2013 08:24 AM, David Rowley wrote:
If it was possible to devise some way to reuse any
previous tuplesortstate perhaps just inventing a reset method which
clears out tuples, then we could see
than using geo_selfuncs.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
DEFAULT_NETWORK_OVERLAP_SELECTIVITY should be renamed
DEFAULT_NETWORK_OVERLAP_SEL and moved to the .c file.
Typo in comment, constrant - constant.
There is an extra empty line at the end of network_selfuncs.c
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
actually planned a query. I do not really like how I check for
if it was replanned, but I tried to avoid making changes in plancache.c.
Does this idea look ok?
--
Andreas Karlsson
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
new file mode 100644
index 2af1738..482490b
backup and logical backup, for example on Barman's
homepage.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/28/2014 09:39 PM, Tom Lane wrote:
I'm for doing the measurement in ExplainOneQuery() and not printing
anything in code paths that don't go through there.
Reading the discussion here and realizing that my last patch was wrong I
am now in agreement with this. I have attached a patch which
On 01/29/2014 09:01 PM, Robert Haas wrote:
Cool. I propose adding one parameter rather than two to
ExplainOnePlan() and making it of type instr_time * rather than
passing an instr_time and a bool. If you don't want to include the
planning time, pass NULL; if you do, pass a pointer to the
On 01/29/2014 10:10 PM, Robert Haas wrote:
Committed with minor doc changes.
Thanks!
/Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is your plan for this?
--
Andreas Karlsson
diff --git a/src/backend/utils/adt/network_selfuncs.c b/src/backend/utils/adt/network_selfuncs.c
new file mode 100644
index 87a7390..3b99afe
*** a/src/backend/utils/adt/network_selfuncs.c
--- b/src/backend/utils/adt/network_selfuncs.c
!
Do you think the new index is useful even if you use the basic
geo_selfuncs? Or should we wait with committing the patches until all
selfuncs are implemented?
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
. pg_receivexlog must be started with postmaster and
monitored with some measures. This won't be very easy at least on Windows.
Replication slots should solve the issue of making sure to catch all of
the WAL.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 04/04/2014 04:01 PM, Andres Freund wrote:
This patch looks like it can be applied much more realistically, but it
looks too late for 9.4. I suggest moving it to the next CF?
If it does not change the default operator class I do not see anything
preventing it from being applied to 9.4, as
On 03/08/2014 10:40 PM, Emre Hasegeli wrote:
Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
Operator name formatting patch rebased on top of it. I will put
the selectivity estimation patch to the next commit fest.
This version of the patch does not touch to the
On 04/17/2014 01:35 AM, Tom Lane wrote:
I'll go change it.
Thanks for fixing this. The new name Execution time is much clearer.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On 04/27/2014 07:07 PM, Tom Lane wrote:
Rewrite timing could easily be captured by EXPLAIN since that call
is done within ExplainQuery(). Parse analysis isn't, but we could
imagine having transformExplainStmt() time the operation and stick
the result into a new field in struct ExplainStmt.
I'm
is almost identical.
--
Andreas Karlsson
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6d26ffc..65483de
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** static const SchemaQuery Query_for_list_
*** 626,631
On 06/09/2014 01:45 PM, Heikki Linnakangas wrote:
Thoughts? While we're at it, we'll probably want to refactor things so
that it's easy to support other SSL implementations too, like gnutls.
There was a patch set for this from Martijn van Oosterhout which was
quite complete.
' to 'Query_for_trigger_of_table' to hide them.
Good suggestion. I have attached a patch which filters out the internal
triggers, both for ALTER TABLE and DROP TRIGGER. I am not entirely sure
about the DROP TRIGGER case but I think I prefer no auto completion of
RI triggers.
--
Andreas Karlsson
diff
On 06/18/2014 02:34 AM, Ian Barwick wrote:
On 14/06/18 7:51, Andreas Karlsson wrote:
On 06/17/2014 01:36 PM, Ian Barwick wrote:
One issue - the table's internal triggers will also be listed. which can
result in
something like this:
This is a bit of an extreme case, but I don't think manually
the Returns X datum comments look redundant to me, but this is a
matter of preference.
- The star when declaring result in ssl_get_extension_names() should be
put on the other side of the white space.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
pass now on my
Debian machine.
One thing I noticed when trying to find the bug is that be-secure.c
still includes some OpenSSL headers. Those should be removed since they
have already been moved to be-secure-openssl.c.
--
Andreas Karlsson
diff --git a/src/backend/libpq/be-secure.c b/src
() is implemented using pg_do_encoding_conversion().
I don't write a code of those functions and I can't answer on your question.
Hm, I thought I saw them changed from static to not in the diff after
applying your patch. Maybe I just misread the patch.
--
Andreas Karlsson
--
Sent via pgsql-hackers
were returned but there
was some way to filter out only the inserted ones.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/28/2014 09:05 PM, Peter Geoghegan wrote:
On Thu, Aug 28, 2014 at 7:29 AM, Andreas Karlsson andr...@proxel.se wrote:
Personally I would find it surprising if RETURNING did not also return the
updated tuples. In many use cases for upsert the user does not care if the
row was new
On 09/28/2014 09:40 AM, Peter Geoghegan wrote:
No explanation of why the CONFLICTING() syntax differs from OLD./NEW.
syntax used in triggers
Why should it be the same?
Both can be seen as cases where you refer to a field of a tuple, which
is usually done with FOO.bar.
--
Andreas Karlsson
Hi,
I have been thinking about why we need to grab an AccessExclusiveLock on
the table with the PK when we add a foreign key. Adding new tables with
foreign keys to old ones is common so it would be really nice if the
lock strength could be reduced.
A comment in the code claims that we need
On 10/22/2014 04:13 PM, Tom Lane wrote:
Andreas Karlsson andr...@proxel.se writes:
I have attached a proof of concept
patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
Why would it have to be self-exclusive? As far as I know we
Hi,
There was recently talk about if we should start using 128-bit integers
(where available) to speed up the aggregate functions over integers
which uses numeric for their internal state. So I hacked together a
patch for this to see what the performance gain would be.
Previous thread:
would take row
locks).
This is just a dream scenario though, and focusing on triggers is indeed
the reasonable goal for 9.5.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On 10/28/2014 02:05 PM, Arthur Silva wrote:
As far as I'm aware int128 types are supported on every major compiler
when compiling for 64bit platforms. Right?
Both gcc and clang support __int128_t, but I do not know about other
compilers like icc and MSVC.
Andreas
--
Sent via
On 10/28/2014 03:40 PM, Heikki Linnakangas wrote:
The patch doesn't do division with the 128-bit integers. It only does
addition and multiplication. Those are pretty straightforward to implement.
The patch uses division when converting from __int128_t to Numeric.
- Andreas
--
Sent via
On 10/28/2014 04:01 PM, Heikki Linnakangas wrote:
Moving on to other issues, isn't 128 bits too small to store the squares
of the processed numbers? That could overflow..
Yeah, which is why stddev_*(int8) and var_*(int8) still have to use
Numeric in the aggregate state. For the int2 and int4
On 11/02/2014 06:41 PM, Tom Lane wrote:
I wrote:
Either way, requiring a dump/reload for upgrade is surely a better answer
for users of the type than just summarily screwing them.
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you
in tuplesort_begin_index_btree()
before /* Prepare SortSupport data for each column */.
- Remove the extra newline after reversedirection().
- End sentences in comments with period. That seems to be the common
practice in the project.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 11/06/2014 02:30 AM, Peter Geoghegan wrote:
Thanks for the review.
On Wed, Nov 5, 2014 at 4:33 PM, Andreas Karlsson andr...@proxel.se wrote:
I looked at the changes to the code. The new code is clean and there is more
code re-use and improved readability. On possible further improvement
On 11/07/2014 08:15 AM, Simon Riggs wrote:
How about we set lock level on each Foreign Key like this
[USING LOCK [lock level]]
level is one of
KEY - [FOR KEY SHARE] - default
ROW - [FOR SHARE]
TABLE SHARE - [ ]
TABLE EXCLUSIVE - [FOR TABLE EXCLUSIVE]
I like the idea and thinks it solves the
Windows machines either.
A couple of things I was not sure about was the naming of the new
functions and if I should ifdef the size of the aggregate state in the
catalog or not.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 11/13/2014 02:03 AM, Andreas Karlsson wrote:
Here is version 2 of the patch which detects the presence of gcc/clang
style 128-bit integers and has been cleaned up to a reviewable state. I
have not added support for any other compilers since I found no
documentation 128-bit support with icc
On 11/13/2014 03:38 AM, Alvaro Herrera wrote:
configure is a generated file. If your patch touches it but not
configure.in, there is a problem.
Thanks for pointing it out, I have now fixed it.
--
Andreas Karlsson
diff --git a/configure b/configure
new file mode 100755
index c4f70e8..bb801b4
On 11/20/2014 01:52 AM, Peter Geoghegan wrote:
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan p...@heroku.com wrote:
Also, I think someone else mentioned this a few months back.
Yeah, that was me.
I think we have three options.
1. Return only inserted tuples
2. Return inserted and updated
the CONCURRENTLY case.
By the way, unless I am mistaken there is currently no protection
against having a concurrent ALTER FUNCTION ... RENAME mess up what is
dumped in by pg_get_triggerdef().
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
I have attached a patch with the current status of my work on reducing
the lock level of trigger and foreign key related DDL.
This commit reduces the lock level of the following commands from ACCESS
EXCLUSIVE to SHARE ROW EXCLUSIVE, plus that it does the same for the
referred table of
lock levels was safe, which Robert,
Tom and others were slightly uncertain about.
Is there anything different here from work in my original patch series?
As far as I know, no.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
git
format which is what I am more used to work with.
--
Andreas Karlsson
--
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 350 matches
Mail list logo
