Hi,
Please find some review for the 2nd patch, with the 1st patch applied
on top of it.
On Sat, Jun 15, 2013 at 6:00 AM, Robert Haas wrote:
> The second patch, dynamic-bgworkers-v1.patch, revises the background
> worker API to allow background workers to be started dynamically.
> This requires s
Hello Fabien,
> > I flag it 'return with feedback', please update the patch so it builds.
> > Everything else is ok.
>
> Here it is.
The patch does not apply and git also whines about trailing space.
It needs a v3...
Please note that a community-agreed behavior on this patch is not yet
acquired
Hi,
Use of this feature is to get call stack for debugging without raising
exception. This definitely seems very useful.
Here are my comments about the submitted patch:
Patch gets applied cleanly (there are couple of white space warning but
that's
into test case file). make and make install too
Hi Simon,
I checked this patch. One thing I could comment on is, do you think it is a good
idea to have oid of exception function list on
contain_volatile_functions_walker()?
The walker function is static thus here is no impact for other caller, and its
"context" argument is unused.
My propositio
Here it is.
The patch does not apply and git also whines about trailing space.
It needs a v3...
The attachement here works for me.
Could you be more precise about the issue?
postgresql> git branch test master
postgresql> git checkout test
Switched to branch 'test'
postgresql> patch -p1
On 2013-06-22 15:10:07 -0400, Robert Haas wrote:
> On Sat, Jun 22, 2013 at 9:16 AM, Cédric Villemain
> wrote:
> > patch is in unified format and apply on HEAD.
> > patch contains documentation, however I believe 'AS IMPLICIT' is a
> > PostgreSQL
> > extension with special behavior and 'AS EXPLICI
Abhijit Menon-Sen wrote:
> Sorry to nitpick, but I don't like that either, on the grounds that if I
> had been in Tom Duffey's place, this addition to the docs wouldn't help
> me to understand and resolve the problem.
>
> I'm not entirely convinced that any brief mention of extra_float_digits
> wo
Le lundi 24 juin 2013 11:44:21, Fabien COELHO a écrit :
> >> Here it is.
> >
> > The patch does not apply and git also whines about trailing space.
> > It needs a v3...
>
> The attachement here works for me.
> Could you be more precise about the issue?
>
> postgresql> git branch test master
>
On 2013-06-24 07:46:34 +0900, Michael Paquier wrote:
> On Mon, Jun 24, 2013 at 7:22 AM, Fujii Masao wrote:
> > Compile error ;)
> It looks like filterdiff did not work correctly when generating the
> latest patch with context diffs, I cannot apply it cleanly wither.
> This is perhaps due to a wron
On 2013-06-12 14:29:59 -0300, Fabrízio de Royes Mello wrote:
> On Fri, May 24, 2013 at 12:22 PM, Fabrízio de Royes Mello <
> fabriziome...@gmail.com> wrote:
>
> > Hi all,
> >
> > I working in a patch to include support of "IF NOT EXISTS" into "CREATE"
> > statements that not have it yet.
> >
> > I
Jaime Casanova writes:
> just tried to build this one, but it doesn't apply cleanly anymore...
> specially the ColId_or_Sconst contruct in gram.y
Please find attached a new version of the patch, v7, rebased to current
master tree and with some more cleanup. I've been using the new grammar
entry N
Hello Noah,
Thanks for your work, your patch is definitely better. I agree that this
approach much more generic.
23.06.2013 20:53, Noah Misch wrote:
The attached revision fixes all above points. Would you look it over? The
area was painfully light on comments, so I added some. I renamed
pgw
On 2013-05-28 09:21:27 -0400, Robert Haas wrote:
> As a general statement, I view this work as something that is likely
> needed no matter which one of the "remove freezing" approaches that
> have been proposed we choose to adopt. It does not fix anything in
> and of itself, but it (hopefully) rem
On 06/24/2013 12:41 AM, Josh Berkus wrote:
Folks,
For 9.2, we adopted it as policy that anyone submitting a patch to a
commitfest is expected to review at least one patch submitted by someone
else. And that failure to do so would affect the attention your patches
received in the future. For t
On 2013-01-25 09:06:12 +0530, Amit Kapila wrote:
> On 01/25/2013 03:43 AM, Jameison Martin wrote:
> > there have been a lot of different threads on this patch. i'm going to
> take a stab at > teasing them out, summarizing them, and addressing them
> individually.
>
> > Is this patch on the CF app?
On 2013-05-21 02:58:25 +0530, Robins Tharakan wrote:
> Attached is an updated patch that does only 1 CREATE DATABASE and reuses
> that for all other tests.
> The code-coverage with this patch goes up from 36% to 70%.
Even creating one database seems superfluous. The plain CREATE DATABASE
has been
Andres Freund wrote:
> On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
>> make maintainer-clean ; ./configure --prefix=$PWD/Debug --enable-debug
>> --enable-cassert --enable-depend --with-libxml --with-libxslt --with-openssl
>> --with-perl --with-python && make -j4 world
>> [ build failure r
On Mon, Jun 17, 2013 at 8:48 PM, Simon Riggs wrote:
> On 17 June 2013 09:03, Pavan Deolasee wrote:
>
>> I agree. We should probably find a better name for this. Any suggestions ?
>
> err, I already made one...
>
>>> But that's not the whole story. I can see some utility in a patch that
>>> makes
Noah Misch wrote:
>> If fixing the behaviour is undesirable, at least the documentation
>> should be fixed.
>
> A brief documentation mention sounds fine. Perhaps add a paragraph on
> constant folding in general and reference that from the CASE page.
How about the attached?
Yours,
Laurenz Albe
Andres Freund writes:
> What about simply not using a keyword at that location at all? Something
> like the attached hack?
"Hack" is much too polite a word for that. This will for example fail
to respect the difference between quoted and unquoted words. If the
argument for this patch is to make
Andres Freund writes:
> Otherwise I think there's not really much left to be done. Fujii?
Well, other than the fact that we've not got MVCC catalog scans yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 21 June 2013 08:31, Dean Rasheed wrote:
> On 21 June 2013 08:02, Dean Rasheed wrote:
>> On 21 June 2013 06:54, David Fetter wrote:
For example "SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file"
>>>
>>> The spec is pretty specific about the "all or none" nature of naming
>>> in the AS
On 2013-06-24 09:57:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Otherwise I think there's not really much left to be done. Fujii?
>
> Well, other than the fact that we've not got MVCC catalog scans yet.
That statement was only about about the patch dealing the removal of
reltoastidxid.
On 2013-06-24 09:55:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > What about simply not using a keyword at that location at all? Something
> > like the attached hack?
>
> "Hack" is much too polite a word for that. This will for example fail
> to respect the difference between quoted and
On Monday, June 24, 2013 5:48 PM Andres Freund wrote:
> On 2013-01-25 09:06:12 +0530, Amit Kapila wrote:
> > On 01/25/2013 03:43 AM, Jameison Martin wrote:
> > > there have been a lot of different threads on this patch. i'm going
> to
> > take a stab at > teasing them out, summarizing them, and add
On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
>
> >> make maintainer-clean ; ./configure --prefix=$PWD/Debug --enable-debug
> >> --enable-cassert --enable-depend --with-libxml --with-libxslt
> >> --with-openssl
Andres Freund wrote:
> On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
>> The contrib/test_logical_decoding/sql/ddl.sql script is generating
>> unexpected results. For both table_with_pkey and
>> table_with_unique_not_null, updates of the primary key column are
>> showing:
>>
>> old-pkey: id
On Mon, Jun 24, 2013 at 3:50 AM, Tom Lane wrote:
> Or maybe they really don't give a damn about breaking
> applications every time they invent a new reserved word?
I think this is the obvious conclusion. In the standard the reserved
words are pretty explicitly reserved and not legal column names,
Amit Kapila writes:
> I will summarize the results, and if most of us feel that they are not good
> enough, then we can return this patch.
Aside from the question of whether there's really any generally-useful
performance improvement from this patch, it strikes me that this change
forecloses othe
On Mon, Jun 24, 2013 at 7:39 PM, Andres Freund wrote:
> On 2013-06-24 07:46:34 +0900, Michael Paquier wrote:
>> On Mon, Jun 24, 2013 at 7:22 AM, Fujii Masao wrote:
>> > Compile error ;)
>> It looks like filterdiff did not work correctly when generating the
>> latest patch with context diffs, I ca
Andres Freund wrote:
> On 2013-06-24 06:44:53 -0700, Kevin Grittner wrote:
>> Andres Freund wrote:
>>> On 2013-06-23 08:27:32 -0700, Kevin Grittner wrote:
> + rm -f '$(DESTDIR)$(bindir)/pg_receivellog$(X)'
Oops. That part is not needed.
>>>
>>> Hm. Why not?
>>
>> Well, I could easily
Greg Stark writes:
> I think their model is that applications work with a certain version
> of SQL and they're not expected to work with a new version without
> extensive updating.
Hm. We could invent a "sql_version" parameter and tweak the lexer to
return keywords added in spec versions later t
Andrew Dunstan writes:
> I think we maybe need to be a bit more careful about a name and shame
> policy, or it will be ignored.
I very much don't like that idea of publishing a list of names either.
Editing the reviewer field and sending personal notices is fine by me,
but name and shame is walki
On 2013-06-24 07:29:43 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-06-23 10:32:05 -0700, Kevin Grittner wrote:
>
> >> The contrib/test_logical_decoding/sql/ddl.sql script is generating
> >> unexpected results. For both table_with_pkey and
> >> table_with_unique_not_null, upda
Maybe this policy should be mentioned on the Wiki, so newbies like myself
(who wouldn't even dare reviewing patches submitted be seasoned hackers)
are not surprised by seeing own name on a shame wall?
M
On 06/24/2013 05:40 PM, Maciej Gajewski wrote:
Maybe this policy should be mentioned on the Wiki, so newbies like
myself (who wouldn't even dare reviewing patches submitted be seasoned
hackers) are not surprised by seeing own name on a shame wall?
I personally would prefer if the email was sent
On 06/24/2013 08:40 AM, Maciej Gajewski wrote:
Maybe this policy should be mentioned on the Wiki, so newbies like
myself (who wouldn't even dare reviewing patches submitted be seasoned
hackers) are not surprised by seeing own name on a shame wall?
It is mentioned. Of course now I can't find it
"Joshua D. Drake" writes:
> In short, leave the ego at the door.
That's not the problem. Let's welcome those who are able to contribute
their time and skills without making it harder for them. Motivation here
shoulnd't be how to avoid getting enlisted on the shame wall.
My opinion is that if we
On 06/24/2013 05:54 PM, Joshua D. Drake wrote:
>
> On 06/24/2013 08:40 AM, Maciej Gajewski wrote:
>> Maybe this policy should be mentioned on the Wiki, so newbies like
>> myself (who wouldn't even dare reviewing patches submitted be seasoned
>> hackers) are not surprised by seeing own name on a sha
On Sat, Jun 22, 2013 at 03:46:49AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > The next limit faced by sorts is
> > INT_MAX concurrent tuples in memory, which limits helpful work_mem to about
> > 150 GiB when sorting int4.
>
> That's frustratingly small. :(
I could a
On Sat, Jun 22, 2013 at 11:36:45AM +0100, Simon Riggs wrote:
> On 13 May 2013 15:26, Noah Misch wrote:
> I'm concerned that people will accidentally use MaxAllocSize. Can we
> put in a runtime warning if someone tests AllocSizeIsValid() with a
> larger value?
I don't see how we could. To preemp
On 06/24/2013 08:01 AM, Dimitri Fontaine wrote:
> Andrew Dunstan writes:
>> I think we maybe need to be a bit more careful about a name and shame
>> policy, or it will be ignored.
>
> I very much don't like that idea of publishing a list of names either.
> Editing the reviewer field and sending p
Josh Berkus writes:
> patch. The vast majority chose not to respond to my email to them at
> all. When private email fails, the next step is public email.
The only problem I have here is that I don't remember about deciding to
publish a list of failures by public email at all. I hope it's not m
Good catch - I've attached a patch to address your point 1. It now returns
the below (i.e. correctly doesn't fill in the saved value if the index is
out of the window. However, I'm not sure whether (e.g.) lead-2-ignore-nulls
means count forwards two rows, and if that's null use the last one you've
On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
> Josh Berkus writes:
>> patch. The vast majority chose not to respond to my email to them at
>> all. When private email fails, the next step is public email.
>
> The only problem I have here is that I don't remember about deciding to
> publish a
On Monday, June 24, 2013, Noah Misch wrote:
> On Sat, Jun 22, 2013 at 03:46:49AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com ) wrote:
> > > The next limit faced by sorts is
> > > INT_MAX concurrent tuples in memory, which limits helpful work_mem to
> about
> > > 150 GiB when so
On 2013-06-24 10:10:11 -0700, Josh Berkus wrote:
> On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
> > Josh Berkus writes:
> >> patch. The vast majority chose not to respond to my email to them at
> >> all. When private email fails, the next step is public email.
> >
> > The only problem I have
> Instead, I don't know, fetch some SPI money to offer a special poster or
> unique one-time-edition only hoodie or a signed mug or whatever to extra
> proficient contributors and turn that into a game people want to win.
I like that idea too. Provided that we allocate enough funding that I
can
On 06/24/2013 10:10 AM, Josh Berkus wrote:
On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
Josh Berkus writes:
patch. The vast majority chose not to respond to my email to them at
all. When private email fails, the next step is public email.
The only problem I have here is that I don't r
>> I will be more than happy to resign as CFM and turn it over to someone
>> else if people have a problem with it.
>
> Heck, Josh. People have to be allowed to critize *a small part* of your
> work without you understanding it as a fundamental request to step back
> from being CFM.
Criticize, y
On Mon, Jun 24, 2013 at 10:54 PM, Josh Berkus wrote:
>
>>> I will be more than happy to resign as CFM and turn it over to someone
>>> else if people have a problem with it.
>>
>> Heck, Josh. People have to be allowed to critize *a small part* of your
>> work without you understanding it as a funda
On 06/24/2013 10:22 AM, Josh Berkus wrote:
Mind you, we wouldn't be able to reward a few reviewers, because they
live in countries to which it's impossible to ship from abroad.
I have previously proposed that all of the reviewers of a given
PostgreSQL release be honored in the release notes as
On Thu, Jun 6, 2013 at 3:01 AM, Amit Kapila wrote:
> To avoid above 3 factors in test readings, I used below steps:
> 1. Initialize the database with scale factor such that database size +
> shared_buffers = RAM (shared_buffers = 1/4 of RAM).
>For example:
>Example -1
> if
On Mon, Jun 24, 2013 at 2:22 PM, Josh Berkus wrote:
> I have previously proposed that all of the reviewers of a given
> PostgreSQL release be honored in the release notes as a positive
> incentive, and was denied on this from doing so. Not coincidentally, we
> don't seem to have any reviewers-at-
On 06/18/2013 09:52 AM, Cédric Villemain wrote:
I've rebased the current set of pending patches I had, to fix pgxs and added 2
new patches.
Bugfixes have already been presented and sent in another thread, except the
last one which only fix comment in pgxs.mk.
The new feature consists in a new
On 2013-06-24 10:37:02 -0700, Joshua D. Drake wrote:
>
> On 06/24/2013 10:22 AM, Josh Berkus wrote:
>
> >Mind you, we wouldn't be able to reward a few reviewers, because they
> >live in countries to which it's impossible to ship from abroad.
> >
> >I have previously proposed that all of the revie
JD said:
> Leave your ego at the door. Josh is doing what could be considered one
> of the most thankless (public) jobs in this project. How about we
> support him in getting these patches taken care of instead of whining
> about the fact that he called us out for not doing our jobs (reviewing
> pa
On Mon, Jun 24, 2013 at 12:57 PM, Josh Berkus wrote:
> Actually, every submitter on that list -- including Maciej -- was sent a
> personal, private email a week ago. A few (3) chose to take the
> opportunity to review things, or promised to do so, including a brand
> new Chinese contributor who n
On 24 June 2013 18:10, Josh Berkus wrote:
> I will be more than happy to resign as CFM and turn it over to someone
> else if people have a problem with it.
Please don't do that (until at least the end of the CF ;-) )
It's a difficult job and I'm happy you're doing it, though I suggest
an optima
> Hrm, I'm on the slackers list, and I didn't see an email directed to
> me from JB in the last week about the CF.
Really? Hmmm. I'm going to send you a test email privately, please
verify whether or not you get it.
> Anyway, I am hoping to take at least one patch this CF, though the
> recent
On Mon, Jun 24, 2013 at 2:41 PM, Andres Freund wrote:
>> I don't like idea of sending gifts. I do like the idea of public thanks. We
>> should put full recognition in the release notes for someone who reviews a
>> patch. If they didn't review the patch, the person that wrote the patch
>> would not
> The problem with that is that that HUGELY depends on the patch and the
> review. There are patches where reviewers do a good percentage of the
> work and others where they mostly tell that "compiles & runs".
This project is enormously stingy with giving credit to people. It's
not like it costs
On 06/24/2013 10:48 AM, Claudio Freire wrote:
Reviewer recognition should be on the same level as the submitter.
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell
On 2013-06-24 14:48:32 -0300, Claudio Freire wrote:
> On Mon, Jun 24, 2013 at 2:41 PM, Andres Freund wrote:
> >> I don't like idea of sending gifts. I do like the idea of public thanks. We
> >> should put full recognition in the release notes for someone who reviews a
> >> patch. If they didn't re
> Because spending a year working on a feature isn't the same as spending
> an hour or day on it. And the proposal was to generally list them at the
> same level.
> At least the 9.3 release notes seem to list people that reviewed
> extensively prominently on the patches...
My proposal was to have
On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
>
> > The problem with that is that that HUGELY depends on the patch and the
> > review. There are patches where reviewers do a good percentage of the
> > work and others where they mostly tell that "compiles & runs".
>
> This project is enormously
On 2013-06-22 14:32:46 +0300, Heikki Linnakangas wrote:
> Attached is a new version that fixes at least the problem I saw. Not sure if
> it fixes what you saw, but it's worth a try. How easily can you reproduce
> that?
Ok, I started to look at this:
* Could you document the way slots prevent chec
On 06/24/2013 10:59 AM, Andres Freund wrote:
On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell that "compiles & r
On Mon, Jun 24, 2013 at 1:24 PM, Joshua D. Drake wrote:
> Leave your ego at the door. Josh is doing what could be considered one of
> the most thankless (public) jobs in this project. How about we support him
> in getting these patches taken care of instead of whining about the fact
> that he call
On Fri, Jun 21, 2013 at 6:29 PM, Troels Nielsen wrote:
> The grammar conflict appears to be because of ambiguities in:
> 1. table_ref (used exclusively in FROM clauses)
> 2. index_elem (used exclusively in INDEX creation statements).
>
> Now, this doesn't seem to make much sense, as AFAICT window
I'm just wondering about newbies...
I've created my first patch, so I'm one of them, I think.
I've reviewed some patches, but only some easier ones, like pure regression
tests. Unfortunately my knowledge is not enough to review patches making
very deep internal changes, or some efficiency tweaks.
On Sat, Jun 22, 2013 at 3:55 PM, Andrew Dunstan wrote:
>> Essentially, cross version upgrade testing runs pg_dumpall from the new
>> version on the old cluster, runs pg_upgrade, and then runs pg_dumpall on the
>> upgraded cluster, and compares the two outputs. This is what we get when the
>> new v
Szymon,
> I've reviewed some patches, but only some easier ones, like pure regression
> tests.
Actually, you were one of the people I was thinking of when I said
"mostly the new submitters have been exemplary in claiming some review
work". You're helping a lot.
> Unfortunately my knowledge is n
On Mon, Jun 24, 2013 at 10:40:48AM -0700, Josh Berkus wrote:
> More, on the slacker list are 6-8 people who I happen to know are paid
> by their employers to work on PostgreSQL. Those are the folks I'm
> particularly targeting with the Slacker list; I want to make it
> transparently clear to thos
Joe, all:
Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
using the packages at yum.postgresql.org. Is the below an issue with
PL/R, the packages, or PostgreSQL?
Seems like if a language is actually *installed*, it needs to have
templates ...
analytics=# \dL
MauMau escribió:
> From: "Alvaro Herrera"
> >Actually, in further testing I noticed that the fast-path you introduced
> >in BackendCleanup (or was it HandleChildCrash?) in the immediate
> >shutdown case caused postmaster to fail to clean up properly after
> >sending the SIGKILL signal, so I had t
Robert Haas writes:
> We probably do need to preserve attribute numbers across an upgrade,
> even for foreign tables. I think those could make their way into
> other places.
Hm ... this argument would also apply to composite types; do we get it
right for those?
regards,
On 2013-06-24 12:24:29 -0700, Josh Berkus wrote:
> Joe, all:
>
> Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
> using the packages at yum.postgresql.org. Is the below an issue with
> PL/R, the packages, or PostgreSQL?
>
> Seems like if a language is actually *installed*,
Josh Berkus writes:
> Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
> using the packages at yum.postgresql.org. Is the below an issue with
> PL/R, the packages, or PostgreSQL?
> Seems like if a language is actually *installed*, it needs to have
> templates ...
Not necessa
> Not necessarily --- that's an optional feature. In fact, I am not eager
> to encourage third-party PLs to start installing pg_pltemplate entries
> anymore, because that's mostly vestigial in the extensions universe.
> We should be encouraging use of CREATE EXTENSION not CREATE LANGUAGE to
> ins
Le lundi 24 juin 2013 19:40:19, Andrew Dunstan a écrit :
> On 06/18/2013 09:52 AM, Cédric Villemain wrote:
> > I've rebased the current set of pending patches I had, to fix pgxs and
> > added 2 new patches.
> >
> > Bugfixes have already been presented and sent in another thread, except
> > the las
On 24 June 2013 15:49, Tom Lane wrote:
> Amit Kapila writes:
>> I will summarize the results, and if most of us feel that they are not good
>> enough, then we can return this patch.
>
> Aside from the question of whether there's really any generally-useful
> performance improvement from this patc
Hello
This is fragment ofmy old code from orafce package - it is functional,
but it is written little bit more generic due impossible access to
static variables (in elog.c)
static char*
dbms_utility_format_call_stack(char mode)
{
MemoryContext oldcontext = CurrentMemoryContext;
ErrorData *e
On Mon, Jun 24, 2013 at 4:05 PM, Simon Riggs wrote:
> I think its rather a shame that the proponents of this patch have
> tried so hard to push this through without working variations on the
> theme. Please guys, go away and get creative; rethink the approach so
> that you can have your lunch with
Simon,
> I think its rather a shame that the proponents of this patch have
> tried so hard to push this through without working variations on the
> theme. Please guys, go away and get creative; rethink the approach so
> that you can have your lunch without anybody else losing theirs. I
> would add
On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen wrote:
> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
> >
> > ALTER TABLE foo
> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED INITIALLY IMMEDIATE;
>
> I read the patch (looks good), applied it on HEAD (fine), ran make check
> (fine)
Robert Haas writes:
> If there's an actual performance consequence of applying this patch,
> then I think that's a good reason for rejecting it. But if the best
> argument we can come up with is that we might someday try to do even
> more clever things with the tuple's natts value, I guess I'm no
On 24 June 2013 21:50, Tom Lane wrote:
> > So, Tom, how's that pluggable storage format coming? :-)
>
> Well, actually, it's looking to me like heap_form_tuple will be
> underneath the API cut, because alternate storage managers will probably
> have other tuple storage formats --- column stores
i believe the last submission of the patch had no negative performance impact
on any of the tested use cases, but you'd have to go back and see the last
exchange on that.
i think it was the concern about potentially regressing the codeline in
unforeseen ways without a clear benefit to all but
On 06/24/2013 01:50 PM, Tom Lane wrote:
> The point of what I was suggesting isn't to conserve storage, but to
> reduce downtime during a schema change. Remember that a rewriting ALTER
> TABLE locks everyone out of that table for a long time.
Right, but I'm worried about the "surprise!" factor.
On 14 March 2013 03:45, Peter Eisentraut wrote:
> On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
> > in this use case I am think so some regression test is important - It
> > should not be mine, but missing more explicit regression test is
> > reason, why this bug was not detected some y
OK - I've attached another iteration of the patch with Troels' grammar
changes. I think the only issue remaining is what the standard says about
lead semantics. Thanks -
lead-lag-ignore-nulls.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Greg Stark wrote:
> On Mon, Jun 24, 2013 at 3:50 AM, Tom Lane wrote:
>> Or maybe they really don't give a damn about breaking
>> applications every time they invent a new reserved word?
>
> I think this is the obvious conclusion. In the standard the reserved
> words are pretty explicitly reserved
On 24 June 2013 21:42, Jeff Janes wrote:
> On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen
> wrote:
>
>> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
>> >
>> > ALTER TABLE foo
>> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED INITIALLY IMMEDIATE;
>>
>> I read the patch (looks go
Josh Berkus writes:
> On 06/24/2013 01:50 PM, Tom Lane wrote:
>> The point of what I was suggesting isn't to conserve storage, but to
>> reduce downtime during a schema change. Remember that a rewriting ALTER
>> TABLE locks everyone out of that table for a long time.
> Right, but I'm worried abo
Hello
you can try fresh patch
git format-patch -1 788bce13d3249ddbcdf3443ee078145f4888ab45
regards
Pavel
2013/6/24 Szymon Guz :
> On 14 March 2013 03:45, Peter Eisentraut wrote:
>>
>> On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
>> > in this use case I am think so some regression t
2013/6/24 Pavel Stehule :
> Hello
>
> you can try fresh patch
>
> git format-patch -1 788bce13d3249ddbcdf3443ee078145f4888ab45
and git format-patch -1 bc61878682051678ade5f59da7bfd90ab72ce13b
>
> regards
>
> Pavel
>
> 2013/6/24 Szymon Guz :
>> On 14 March 2013 03:45, Peter Eisentraut wrote:
>>>
On 06/24/2013 03:39 PM, Tom Lane wrote:
Robert Haas writes:
We probably do need to preserve attribute numbers across an upgrade,
even for foreign tables. I think those could make their way into
other places.
Hm ... this argument would also apply to composite types; do we get it
right for tho
On Wed, Jun 19, 2013 at 12:44 AM, Alexander Korotkov
wrote:
> On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov
> wrote:
>
>> On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov <
>> aekorot...@gmail.com> wrote:
>>
>>> Revised version of patch for additional information storage in GIN is
>>> a
On 06/24/2013 04:02 PM, Cédric Villemain wrote:
WIth extension, we do have to set VPATH explicitely if we want to use VPATH
(note that contribs/extensions must not care that postgresql has been built
with or without VPATH set). My patches try to fix that.
No, this is exactly what I'm obje
1 - 100 of 146 matches
Mail list logo
