2013-12-21 14:56 keltezéssel, Peter Eisentraut írta:
This patch didn't make it out of the 2013-11 commit fest. You should
move it to the next commit fest (probably with an updated patch)
before January 15th.
Done.
Best regards,
Zoltán Böszörményi
--
--
Zoltán
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler da...@justatheory.com wrote:
* New operators:
+ `hstore - int`: Get string value at array index (starting at 0)
+ `hstore ^ text`:Get numeric value for key
+ `hstore ^ int`: Get numeric value at array index
+ `hstore ?
On 12/23/2013 12:28 PM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler da...@justatheory.com
wrote:
* New operators:
+ `hstore - int`: Get string value at array index (starting at 0)
+ `hstore ^ text`:Get numeric value for key
+ `hstore ^ int`: Get
On 2013-12-22 20:45:02 -0500, Robert Haas wrote:
I suspect we ought to extend this to rewriting variants of ALTER TABLE
as well, but a little thought is needed there. ATRewriteTables()
appears to just call heap_insert() for each updated row, which if I'm
not mistaken is an MVCC violation -
On Fri, Dec 20, 2013 at 9:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund and...@2ndquadrant.com wrote:
I wondered that, too, but it's not well-defined for all tuples. What
happens if you pass in constructed tuple rather than an on-disk tuple?
On 2013-12-20 13:22:07 +0100, Andres Freund wrote:
On 2013-12-20 07:12:01 -0500, Robert Haas wrote:
I think the root of the problem is that nobody's very eager to add
more hidden system catalog columns because each one bloats
pg_attribute significantly.
I think that part is actually
On 2013-12-20 21:56:42 -0500, Robert Haas wrote:
On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund and...@2ndquadrant.com wrote:
I wondered that, too, but it's not well-defined for all tuples. What
happens if you pass in constructed tuple rather than an on-disk tuple?
Those should be
On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-12-20 13:22:07 +0100, Andres Freund wrote:
On 2013-12-20 07:12:01 -0500, Robert Haas wrote:
I think the root of the problem is that nobody's very eager to add
more hidden system catalog columns because each
On 2013-12-23 10:26:49 -0500, Robert Haas wrote:
On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund and...@2ndquadrant.com wrote:
I've spent some time yesterday hacking up a prototype for this. The
amount of effort seems reasonable, although the attached patch certainly
doesn't do all the
On 12/21/13, 9:39 AM, Peter Eisentraut wrote:
This is enabling large-file support on OS X, so that seems kind of
important. It's not failing with newer versions of OS X, so that leaves
the following possibilities, I think:
- Large files never worked on 10.5. That would be strange because
On Sun, Dec 22, 2013 at 6:42 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Dec 20, 2013 at 11:59 PM, Peter Geoghegan p...@heroku.com wrote:
I think that the way forward is to refine my design in order to
upgrade locks from exclusive buffer locks to something else, managed
by the lock
Hello
2013/12/23 Hannu Krosing ha...@2ndquadrant.com
On 12/23/2013 12:28 PM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler da...@justatheory.com
wrote:
* New operators:
+ `hstore - int`: Get string value at array index (starting at 0)
+ `hstore ^ text`:
On Mon, Dec 23, 2013 at 10:42 AM, Andres Freund and...@2ndquadrant.com wrote:
But TBH, I'm kind of enamored of the function-based approach at the
moment. It just seems a lot more flexible. Adding a function is
nearly free and we can add as many as we need doing whatever we want,
and they can
On Dec 19, 2013 12:06 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi Magnus,
It looks to me like the path to do_pg_start_backup() outside of a
transaction context comes from your initial commit of the base backup
facility.
The problem is that you're not allowed to do anything leading to
I wrote:
Or, really, why don't we just do the same thing I'm advocating for
the plain-ordered-set case? That is, if there's a single collation
applying to all the collatable inputs, that's the collation to use
for the aggregate; otherwise it has no determinate collation, and
it'll throw an
On 12/19/13, 6:40 PM, Florian Pflug wrote:
The following example fails for XMLOPTION set to DOCUMENT as well as for
XMLOPTION set to CONTENT.
select xmlconcat(
xmlparse(document '!DOCTYPE test [!ELEMENT test EMPTY]test/'),
xmlparse(content 'test/')
)::text::xml;
The SQL
On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
it is here.
$ psql
=# ALTER SYSTEM SET shared_buffers = '512MB';
ALTER
On Dec 23, 2013, at 6:28 AM, Robert Haas wrote:
On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler da...@justatheory.com
wrote:
* New operators:
+ `hstore - int`: Get string value at array index (starting at 0)
+ `hstore ^ text`:Get numeric value for key
+ `hstore ^ int`: Get
Robert Haas robertmh...@gmail.com wrote:
Meh. Who are all of these people who are fetching xmin, xmax, cmin,
and cmax in complex queries, and why are they doing that? If those
columns are just for forensic purposes, then whatever performance
disadvantages the function-based approach has
Discussion around this topic has reached hundreds of messages, and
whilst I have failed to find mention of my following question, I
appreciate it may have already been discussed.
I have noticed that configuration parameters for extensions are only
supported if the server was started with one of
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom What I'm now thinking we want to do is:
Tom 1. Non-hypothetical direct args always contribute to determining
Tom the agg's collation.
Tom 2. Hypothetical and aggregated args contribute to the agg's
Tom collation only if the agg is designed so
On 2013-12-23 10:56:07 -0500, Robert Haas wrote:
Well, it really depends on the usecase. Reading
SELECT header.xmin, header.xmax
FROM sometable tbl,
pg_tuple_header(tbl.tableoid, tbl.ctid) header;
is surely harder to understand than
SELECT tbl.xmin, tbl.xmax
FROM sometable tbl;
On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown t...@linux.com wrote:
Discussion around this topic has reached hundreds of messages, and
whilst I have failed to find mention of my following question, I
appreciate it may have already been discussed.
I have noticed that configuration parameters for
On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund and...@2ndquadrant.com wrote:
Well, all of the fundamental changes (combocids, the initial multixact
introduction) have been quite some time ago. I think backward compat has
a much higher value these days (I also don't see much point in looking
at
On 23 December 2013 19:14, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown t...@linux.com wrote:
Discussion around this topic has reached hundreds of messages, and
whilst I have failed to find mention of my following question, I
appreciate it may have
On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown t...@linux.com wrote:
I would think that you'd need to have auto_explain loaded in the
backend where you're trying to make a change, but you shouldn't need
the setting to be present in postgresql.conf, I would think.
This appears to be the case. I
On 23 December 2013 19:35, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown t...@linux.com wrote:
I would think that you'd need to have auto_explain loaded in the
backend where you're trying to make a change, but you shouldn't need
the setting to be present
On Fri, Nov 15, 2013 at 09:51:32AM -0500, Robert Haas wrote:
On Wed, Nov 13, 2013 at 11:04 AM, Noah Misch n...@leadboat.com wrote:
So, in short, ERROR + ERROR*10 = PANIC, but FATAL + ERROR*10 = FATAL.
That's bizarre.
Quite so.
Given that that's where we are, promoting an ERROR during
On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The only animal we have that doesn't support quiet inlines today is
HP-UX/ac++, and I think - as in patch 1 in the series -
Atri Sharma atri.j...@gmail.com writes:
Please find attached the latest patch for WITHIN GROUP. This patch is
after fixing the merge conflicts.
I've committed this after significant editorialization --- most notably,
I pushed control of the sort step into the aggregate support functions.
I
On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas robertmh...@gmail.com wrote:
I don't think this is a project to rush through. We've lived without
MERGE/UPSERT for several years now, and we can live without it for
another release cycle while we try to reach agreement on the way
forward. I can
With \timing on, a trailing comment yields a timing.
# test.sql
select 1;
/*
select 2
*/
$ psql -f test.sql
?column?
--
1
(1 row)
Time: 0.651 ms
Time: 0.089 ms
I assume it is timing something about that comment (right?).
Confusing and annoying, IMHO. Is there any chance
Hi,
A user asked in -performance[1] if there is a way to measure the
planning time. Other than measuring it in the client I do not think
there is so I quickly hacked a patched which adds Planning time to the
outputs of EXPLAIN and EXPLAIN ANALYZE.
Is this something useful? I think it is,
On 12/24/2013 02:05 AM, Erik Rijkers wrote:
With \timing on, a trailing comment yields a timing.
# test.sql
select 1;
/*
select 2
*/
$ psql -f test.sql
?column?
--
1
(1 row)
Time: 0.651 ms
Time: 0.089 ms
I assume it is timing something about that comment (right?).
On 12/22/2013 04:38 PM, Alexander Korotkov wrote:
postgres=# explain analyze select * from test order by v1, id limit 10;
QUERY
PLAN
Andreas Karlsson wrote
On 12/24/2013 02:05 AM, Erik Rijkers wrote:
With \timing on, a trailing comment yields a timing.
# test.sql
select 1;
/*
select 2
*/
$ psql -f test.sql
?column?
--
1
(1 row)
Time: 0.651 ms
Time: 0.089 ms
I assume it is timing something
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.
regards, tom lane
--
Sent via pgsql-hackers
On 12/24/2013 03:17 AM, David Johnston wrote:
I need to be convinced that the server should not just silently ignore
trailing comments. I'd consider an exception if the only text sent is a
comment ( in such a case we should throw an error ) but if valid commands
are sent and there is just some
On 23-12-2013 22:12, Andreas Karlsson wrote:
A user asked in -performance[1] if there is a way to measure the
planning time. Other than measuring it in the client I do not think
there is so I quickly hacked a patched which adds Planning time to the
outputs of EXPLAIN and EXPLAIN ANALYZE.
Is
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 that
On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson andr...@proxel.se wrote:
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
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson andr...@proxel.se wrote:
Yeah, forgot to mention that we need some way to disable it in the tests.
Either by not having it included in EXPLAIN or by adding an option to turn
it off. Any suggestion on
On Mon, Dec 23, 2013 at 10:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson andr...@proxel.se wrote:
Yeah, forgot to mention that we need some way to disable it in the tests.
Either by not having it included
On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier escribió:
On Fri, Dec 20, 2013 at 1:05 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Sorry the patch which I
On Mon, Dec 23, 2013 at 5:59 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas robertmh...@gmail.com wrote:
I don't think this is a project to rush through. We've lived without
MERGE/UPSERT for several years now, and we can live without it for
another
This is a small patch to fix a typo in src/backend/utils/mmgr/README.
Thanks,
Best regards,
Etsuro Fujita
typofix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi all
I'm finding it necessary to remap the varno and varattno of Var elements
in RETURNING lists as part of updatable s.b. view processing. A
reference to a view col in RETURNING must be rewritten to point to the
new resultRelation at the top level, so that the effects of BEFORE
triggers are
On 12/24/2013 02:35 PM, Craig Ringer wrote:
So the short version: Given the RTE for a simple view with only one base
rel and an attribute number for a col in that view, and assuming that
the view col is a simple reference to a col in the underlying base rel,
is there any sane way to get the
On Tue, Dec 24, 2013 at 11:47 AM, Craig Ringer cr...@2ndquadrant.comwrote:
On 12/24/2013 02:35 PM, Craig Ringer wrote:
So the short version: Given the RTE for a simple view with only one base
rel and an attribute number for a col in that view, and assuming that
the view col is a simple
On Tue, Dec 24, 2013 at 03:40:58AM +0100, Andreas Karlsson wrote:
On 12/24/2013 03:17 AM, David Johnston wrote:
It is not sent to the server as a trailing comment. The following
file is sent to the server like this.
File:
/**/;
/**/
Commands:
PQexec(..., /**/;);
PQexec(..., /**/);
50 matches
Mail list logo
