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(...
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 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
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
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
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
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 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
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 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
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 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: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
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
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
On 12/22/2013 04:38 PM, Alexander Korotkov wrote:
postgres=# explain analyze select * from test order by v1, id limit 10;
QUERY
PLAN
-
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
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
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
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
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 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
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 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 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: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 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 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 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
> "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
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
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.
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
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 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
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 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/
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
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 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
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 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 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-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 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 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-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 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 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
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
50 matches
Mail list logo
