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 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 ?> text`:Get boo
On 12/23/2013 12:28 PM, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler
> 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 val
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 wrote:
> On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund 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 discernible I thin
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 actua
On 2013-12-20 21:56:42 -0500, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 7:51 AM, Andres Freund 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 discernible I thin
On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund 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 one bloats
>>
On 2013-12-23 10:26:49 -0500, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund 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 neccessary things. Th
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 becau
On Sun, Dec 22, 2013 at 6:42 PM, Peter Geoghegan wrote:
> On Fri, Dec 20, 2013 at 11:59 PM, Peter Geoghegan 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 manager but perhaps through
Hello
2013/12/23 Hannu Krosing
> On 12/23/2013 12:28 PM, Robert Haas wrote:
> > On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler
> wrote:
> >> * New operators:
> >> + `hstore -> int`: Get string value at array index (starting at 0)
> >> + `hstore ^> text`:Get numeric value for key
On Mon, Dec 23, 2013 at 10:42 AM, Andres Freund 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 even go into c
On Dec 19, 2013 12:06 AM, "Andres Freund" 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 a
> syscache/
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
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 ']>'),
> xmlparse(content '')
> )::text::xml;
The SQL standard specifies that DTDs are dropped b
On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao 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 SYSTEM
>> =# \q
>> $ pg_ctl -D d
On Dec 23, 2013, at 6:28 AM, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 6:16 PM, David E. Wheeler
> 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
Robert Haas 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 don't really matter.
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 th
> "Tom" == Tom Lane 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 that t
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 som
On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown 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 extension
On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund 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 cmin/cmax for anyt
On 23 December 2013 19:14, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 1:42 PM, Thom Brown 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 ha
On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown 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 hadn't
On 23 December 2013 19:35, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 2:19 PM, Thom Brown 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 woul
On Fri, Nov 15, 2013 at 09:51:32AM -0500, Robert Haas wrote:
> On Wed, Nov 13, 2013 at 11:04 AM, Noah Misch 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 FA
On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund wrote:
> On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
>> Andres Freund 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 - we might be able
>> > to simply suppr
Atri Sharma 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 didn't like the way no
On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas 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 tell that you're con
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 such
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, s
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?).
Confusi
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
Andreas Karlsson 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 mailing list (pg
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 c
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.
On 12/24/2013 03:33 AM, Tom Lane wrote:
Andreas Karlsson 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 we need some way t
On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson wrote:
> On 12/24/2013 03:33 AM, Tom Lane wrote:
>>
>> Andreas Karlsson 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
Robert Haas writes:
> On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson 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 which would be preferable?
> I wo
On Mon, Dec 23, 2013 at 10:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 23, 2013 at 9:54 PM, Andreas Karlsson 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
On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas wrote:
> On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
> wrote:
>> Michael Paquier escribió:
>>> On Fri, Dec 20, 2013 at 1:05 PM, Sawada Masahiko
>>> wrote:
>>
>>> > Sorry the patch which I attached has wrong indent on pg_controldata.
>>> > I have
On Mon, Dec 23, 2013 at 5:59 PM, Peter Geoghegan wrote:
> On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas 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 rea
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:
http://www.postgresql.org/mailpref/pgsql
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 vis
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 th
On Tue, Dec 24, 2013 at 11:47 AM, Craig Ringer wrote:
> 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 c
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
