On Tue, Sep 21, 2010 at 1:17 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
>> though. IMHO there should be a new COPY IN+OUT mode.
>
> Yeah, I was going to make the same complaint. Breaking basic
> error-checking functi
Starting looking at the latest MERGE patch from Boxuan here tonight. The
regression tests pass for me here, good starting sign. I expect to move
onto trying to break it more creatively next, then onto performance
tests. Nothing much more exciting than that to report so far.
It had suffered som
Any updates on this?
On Tue, Sep 21, 2010 at 10:47 PM, Sushant Sinha wrote:
> > I looked at this patch a bit. I'm fairly unhappy that it seems to be
> > inventing a brand new mechanism to do something the ts parser can
> > already do. Why didn't you code the url-part mechanism using the
> > ex
On Wed, Sep 29, 2010 at 12:53 PM, Josh Kupershmidt wrote:
> I thought this paragraph was a little confusing:
Thanks for checking.
> ! In the second case, a full table scan is followed by a sort operation.
> ! The method is faster than the first one when the table is highly
> fragmented.
Andrew Dunstan wrote:
On 09/28/2010 09:31 PM, Darren Duncan wrote:
Code that quotes all of its identifiers, such as with:
FOR EACH "var" IN "array_expr" LOOP ...
This doesn't help in the least if the array is an expression rather than
simply a variable - we're not going to start quoting e
On Wed, Sep 29, 2010 at 1:27 PM, Alvaro Herrera
wrote:
>> I see a consistent
>> ~10% advantage for the sequential scan clusters.
>
> 10% is nothing. I was expecting this patch would give an order of
> magnitude of improvement or somethine like that in the worst cases of
> the current code (highly
2010/9/28 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/28 Tom Lane :
>>> Sure it can: it could be a parenthesized top-level query. In fact,
>>> that's what plpgsql will assume if you feed it that syntax today.
>
>> no - there are not any legal construct FOR r IN (..)
>
> You are simply wrong, sir
Excerpts from Josh Kupershmidt's message of mar sep 28 23:53:33 -0400 2010:
> I started looking at the performance impact of this patch based on
> Leonardo's SQL file. On the 2 million row table, I see a consistent
> ~10% advantage for the sequential scan clusters. I'm going to try to
> run the bi
On Mon, Sep 27, 2010 at 10:05 PM, Itagaki Takahiro
wrote:
> I re-ordered some description in the doc. Does it look better?
> Comments and suggestions welcome.
I thought this paragraph was a little confusing:
! In the second case, a full table scan is followed by a sort operation.
! The m
On Tue, Sep 28, 2010 at 5:23 PM, Magnus Hagander wrote:
>> When I ran that, the size of the WAL file in inprogress directory
>> became more than 16MB. Obviously something isn't right.
>
> Wow, that's weird. I'm unable to reproduce that here - can you try to
> figure out why that happened?
Sorry,
Robert Haas writes:
> ...what makes the pathkeys potentially useful is that they match the
> root pathkeys for the query. However, without Greg's hacks, the
> transposed child equivalence classes don't show up in the equivalence
> member lists, so get_eclass_for_sort_expr() generates new equivale
On Thu, Sep 9, 2010 at 8:57 PM, Pavel Stehule wrote:
> I am sending a updated version.
>
> changes:
> * tag %v removed from format function,
> * proprietary tags %lq a iq removed from sprintf
> * code cleaned
>
> patch divided to two parts - format function and stringfunc (contains
> sprintf funct
So we've got two patches that implement synchronous replication, and
no agreement on which one, if either, should be committed. We have no
agreement on how synchronous replication should be configured, and at
most a tenuous agreement that it should involve standby registration.
This is bad.
This
On 09/28/2010 09:43 PM, Darren Duncan wrote:
Alvaro Herrera wrote:
What about
FOR EACH var IN array_expr LOOP ...
I think this requires reserving EACH, which could cause a regression for
working code. Maybe there's a way to make it work?
What about saying FOR-EACH instead?
A good general
On 09/28/2010 09:31 PM, Darren Duncan wrote:
Alvaro Herrera wrote:
What about
FOR EACH var IN array_expr LOOP ...
I think this requires reserving EACH, which could cause a regression for
working code. Maybe there's a way to make it work?
Code that quotes all of its identifiers, such as wi
On Tue, Sep 28, 2010 at 9:33 PM, Itagaki Takahiro
wrote:
> On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas wrote:
>> No, the column is very clearly labelled "Reviewers", not "Reviewer".
>> And we have certainly had patches with more than one person's name in
>> that field in the past. The issue is
2010/9/28 Robert Haas :
> 2010/9/23 Robert Haas :
>> All of this leaves me wondering why Greg ended up ifdefing out this
>> code in the first place. There's probably something I'm missing
>> here... but for now I can't think of a better idea than just removing
>> the #ifdefs and hoping that whate
Alvaro Herrera writes:
> Excerpts from Kevin Grittner's message of mar sep 28 12:28:12 -0400 2010:
>> How about distinguishing it this way:?
>> FOR var IN ARRAY array_expression LOOP
> What about
> FOR EACH var IN array_expr LOOP ...
That doesn't seem to have any obvious connection to looping ov
Alvaro Herrera wrote:
What about
FOR EACH var IN array_expr LOOP ...
I think this requires reserving EACH, which could cause a regression for
working code. Maybe there's a way to make it work?
What about saying FOR-EACH instead?
A good general solution that I'd expect to not cause regressio
On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas wrote:
> No, the column is very clearly labelled "Reviewers", not "Reviewer".
> And we have certainly had patches with more than one person's name in
> that field in the past. The issue is rather that we don't have enough
> people reviewing. We haven
Alvaro Herrera wrote:
What about
FOR EACH var IN array_expr LOOP ...
I think this requires reserving EACH, which could cause a regression for
working code. Maybe there's a way to make it work?
Code that quotes all of its identifiers, such as with:
FOR EACH "var" IN "array_expr" LOOP ...
2010/9/23 Robert Haas :
> All of this leaves me wondering why Greg ended up ifdefing out this
> code in the first place. There's probably something I'm missing
> here... but for now I can't think of a better idea than just removing
> the #ifdefs and hoping that whatever problem they were causing
On Tue, Sep 28, 2010 at 9:11 PM, Itagaki Takahiro
wrote:
> On Wed, Sep 29, 2010 at 6:03 AM, David Fetter wrote:
>> The Good:
>> - Most patches still in play have a reviewer.
>
> As far as I remember, there were discussions about the issue
> "A patch has a reviewer, but in Needs Review state for s
Excerpts from Kevin Grittner's message of mar sep 28 12:28:12 -0400 2010:
> How about distinguishing it this way:?
>
> FOR var IN ARRAY array_expression LOOP
What about
FOR EACH var IN array_expr LOOP ...
I think this requires reserving EACH, which could cause a regression for
working code.
On Wed, Sep 29, 2010 at 6:03 AM, David Fetter wrote:
> The Good:
> - Most patches still in play have a reviewer.
As far as I remember, there were discussions about the issue
"A patch has a reviewer, but in Needs Review state for several weeks "
in 9.0 development.
Do we have any plans for it? Ac
On Tue, Sep 28, 2010 at 6:16 PM, Magnus Hagander wrote:
> We're talking about the "export all symbols" thing, right? I *don't*
> think we want to recommend people to do that - it creates bloated DLL
> files, for no really good reason. Also, it's not just a matter of a
> msvc project - we do that w
Tom Lane writes:
> Hmm, you're right. I only tested that on Latin1 characters, for which
> it does work because those have Unicode points below 256. I'm not
> sure of a reasonable solution for the general case --- we certainly
> don't want this function iterating up to 2^21 or thereabouts.
Yes
On 09/28/2010 03:41 PM, Pavel Stehule wrote:
It's not simple - FOR i IN array is natural - Original ADA use a very
similar construct.
No it doesn't. In Ada (Note: not ADA) FOR can only iterate over one
thing: a discrete subtype (e.g. an integer or enumeration type, or a
range of it)[1].
Sergey Burladyan writes:
> As i can see in Tom's patch 0d323425 only functions like pg_wc_isalpha is
> changed, but
> this pg_wc_isalpha is called from
> static struct cvec *
> cclass(struct vars * v,/* context */
>const chr *startp, /* where the name starts */
>c
Massa, Harald Armin wrote:
> Bruce,
>
> >
> > > NET STOP postgresql-8.4
> > > NET STOP postgresql-9.0
> >
>
>
> > > which should be extended by
> > >
> > > net stop postgresql-x64-9.0
> > >
> > > for Windows 64 bit.
> > >
> >
> > Interesting. What I have added to HEAD and 9.0 docs is the attach
I see this in 9.0 Release note:
- Support locale-specific regular expression processing with UTF-8
server encoding (Tom Lane)
Locale-specific regular expression functionality includes
case-insensitive matching and locale-specific character classes.
But character classes still does not wo
Pavel Stehule writes:
> 2010/9/28 Tom Lane :
>> Sure it can: it could be a parenthesized top-level query. Â In fact,
>> that's what plpgsql will assume if you feed it that syntax today.
> no - there are not any legal construct FOR r IN (..)
You are simply wrong, sir, and I suggest that you go re
Folks,
We're almost half way through the commitfest, and so I'll start with:
The Good:
- Most patches still in play have a reviewer.
- It's possible for one person to post 5 reviews in a day. Robert
Haas actually did this on his own time yesterday.
- New people have been reviewing patches,
On Tue, Sep 28, 2010 at 4:39 PM, Pavel Stehule wrote:
> 2010/9/28 Tom Lane :
>> Pavel Stehule writes:
>>> 2010/9/28 Tom Lane :
As an example, is this a for-in-query or a
for-in-array?
FOR v IN (SELECT arraycol FROM tab) LOOP ...
>>
>>> This is a subquery - so it is a fo
2010/9/28 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/28 Tom Lane :
>>> Yes, there is. The syntax you propose is flat out ambiguous: there are
>>> two possible legal interpretations of some commands.
>
>> what are you thinking? The subquery cannot be interpreted different.
>
> Sure it can: it co
2010/9/28 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/28 Tom Lane :
>>> As an example, is this a for-in-query or a
>>> for-in-array?
>>>
>>> FOR v IN (SELECT arraycol FROM tab) LOOP ...
>
>> This is a subquery - so it is a for-in-array - should return one row
>> with one column.
>
> That's
Pavel Stehule writes:
> 2010/9/28 Tom Lane :
>> Yes, there is. Â The syntax you propose is flat out ambiguous: there are
>> two possible legal interpretations of some commands.
> what are you thinking? The subquery cannot be interpreted different.
Sure it can: it could be a parenthesized top-lev
Pavel Stehule writes:
> 2010/9/28 Tom Lane :
>> As an example, is this a for-in-query or a
>> for-in-array?
>>
>> Â Â Â Â FOR v IN (SELECT arraycol FROM tab) LOOP ...
> This is a subquery - so it is a for-in-array - should return one row
> with one column.
That's not obvious at all. It's le
2010/9/28 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/28 Tom Lane :
>>> But I guess you could get around that if you had to by putting the ARRAY
>>> expression inside parens, and it would be a pretty darn unusual case
>>> anyway. So this is probably the best choice.
>
>> I don't agree - There is
Pavel Stehule writes:
> 2010/9/28 Tom Lane :
>> But I guess you could get around that if you had to by putting the ARRAY
>> expression inside parens, and it would be a pretty darn unusual case
>> anyway. Â So this is probably the best choice.
> I don't agree - There isn't reason for complicating
Bruce,
>
> > NET STOP postgresql-8.4
> > NET STOP postgresql-9.0
>
> > which should be extended by
> >
> > net stop postgresql-x64-9.0
> >
> > for Windows 64 bit.
> >
>
> Interesting. What I have added to HEAD and 9.0 docs is the attached
> patch that explains the proper service name should be
2010/9/28 Tom Lane :
> "Kevin Grittner" writes:
> FOR var IN [array variable | array expression]
> LOOP
>
>> How about distinguishing it this way:?
>
>> FOR var IN ARRAY array_expression LOOP
I see one problem - when you can use a constant array, then you will
write two keywords ARRAY
FO
2010/9/28 Tom Lane :
> Pavel Stehule writes:
>> I looked on some constructs that helps with iteration over array in
>> plpgsql. I propose a following syntax:
>
>> FOR var IN [array variable | array expression]
>> LOOP
>
> I don't have any opinion about whether the functionality proposed here
> is
On 09/28/10 17:26, Robert Haas wrote:
First, it seems totally wrong to assume that the same functions and
operators will be defined on the remote side as you have locally;
indeed, for CSV files, you won't have anything defined on the remote
side at all. You need some kind of a discovery mechanis
Massa, Harald Armin wrote:
> Hello,
>
> just doing an upgrade form PostgreSQL 8.4.4 on Windows 2007 64bit to
> PostgreSQL 9.0 64bit on the same system.
>
> I am working along
> http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
>
> There is written:
>
> NET STOP postgresql-8.4
> NET
Peter Eisentraut writes:
> On tis, 2010-09-28 at 12:18 -0400, Tom Lane wrote:
>> It would be good to get rid of this whitespace because (I believe) it is
>> one of very few reasons for needing to have any trailing whitespace in
>> git-controlled files. If we could get to a point where trailing
>>
On tis, 2010-09-28 at 12:18 -0400, Tom Lane wrote:
> I'm inclined to think that that's not a fatal objection; it's not like
> we haven't felt free to change psql's output format before. As long as
> we don't back-patch this change, it should be no worse than other things
> we've done to third-part
On mån, 2010-09-27 at 11:09 -0700, David Fetter wrote:
> I must be missing something pretty crucial here as far as the
> complexity of changing all the regression tests. Wouldn't trimming
> all trailing whitespace do the trick?
No, there is trailing whitespace that is significant.
--
Sent via
David Fetter writes:
> On Mon, Sep 27, 2010 at 03:11:07PM -0400, Robert Haas wrote:
>> Sure. But everyone using pg_regress will have to update their
>> regression test expected outputs.
> Again, I must be missing something super important. What is it that
> prevents people from doing
> find . -
"Kevin Grittner" writes:
FOR var IN [array variable | array expression]
LOOP
> How about distinguishing it this way:?
> FOR var IN ARRAY array_expression LOOP
That occurred to me too, but it's got a small problem: it's not
impossible for ARRAY to be the first token of a valid scalar
Robert Haas wrote:
>>> FOR var IN [array variable | array expression]
>>> LOOP
>>
>> I don't have any opinion about whether the functionality proposed
>> here is worth the trouble, but I do have an opinion about that
>> syntax: it's an awful choice.
>
> I agree, on both points.
How about distin
On Tue, Sep 28, 2010 at 12:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 27, 2010 at 2:09 PM, David Fetter wrote:
>>> I must be missing something pretty crucial here as far as the
>>> complexity of changing all the regression tests. Wouldn't trimming
>>> all trailing whitespace do
Robert Haas writes:
> On Mon, Sep 27, 2010 at 2:09 PM, David Fetter wrote:
>> I must be missing something pretty crucial here as far as the
>> complexity of changing all the regression tests. Wouldn't trimming
>> all trailing whitespace do the trick?
> Sure. But everyone using pg_regress will
On Sep 28, 2010, at 7:41 AM, Robert Haas wrote:
>> I don't have any opinion about whether the functionality proposed here
>> is worth the trouble, but I do have an opinion about that syntax: it's
>> an awful choice.
>
> I agree, on both points.
>
> It's nice to try to reduce the excess verbosity
On Tue, Sep 28, 2010 at 3:22 PM, Robert Haas wrote:
> On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut wrote:
> > On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
> >> On Tue, Sep 28, 2010 at 13:50, Robert Haas
> wrote:
> >> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> >> >> Th
got it folks. Forgot that elog doesn't return with ERROR
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/9/28 Grzegorz Jaśkiewicz :
> 2010/9/28 Tom Lane :
>> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
>>> It would crash if input is of unrecognized format. Probably than
>>> there's going to be more problems to be concerned with, but just in
>>> case, don't crash in
>>
>> I'm not sure why you th
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> ...
> rp = result = NULL; /* keep compiler quiet */
> }
> *rp = '\0';
>
> this strikes me as a clear case of possible null pointer dereference,
> wouldn't you agree ?
No, I wouldn't. You need to enla
On Tue, Sep 28, 2010 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> Another angle on this problem is that, at least AFAICT, the duplicate
>> OIDs are completely harmless so long as they are in different
>> catalogs. And if they are in the same catalog, then initdb will fail
>> (and shame
2010/9/28 Tom Lane :
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
>> It would crash if input is of unrecognized format. Probably than
>> there's going to be more problems to be concerned with, but just in
>> case, don't crash in
>
> I'm not sure why you think this is a good change, but it would
Robert Haas writes:
> Another angle on this problem is that, at least AFAICT, the duplicate
> OIDs are completely harmless so long as they are in different
> catalogs. And if they are in the same catalog, then initdb will fail
> (and shame on you if you don't notice that). Long, long ago
> pg_de
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> It would crash if input is of unrecognized format. Probably than
> there's going to be more problems to be concerned with, but just in
> case, don't crash in
I'm not sure why you think this is a good change, but it would break
things: in particular,
On tis, 2010-09-28 at 09:22 -0400, Robert Haas wrote:
> > I think it should actually be run as part of the regular build.
> Ever
> > since I started using git and developing like 10 features at once,
> and
> > other people doing the same, the chances of (hidden) OID conflicts
> is
> > growing imme
On Tue, Sep 28, 2010 at 10:34 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> I looked on some constructs that helps with iteration over array in
>> plpgsql. I propose a following syntax:
>
>> FOR var IN [array variable | array expression]
>> LOOP
>
> I don't have any opinion about whether the fun
Pavel Stehule writes:
> I looked on some constructs that helps with iteration over array in
> plpgsql. I propose a following syntax:
> FOR var IN [array variable | array expression]
> LOOP
I don't have any opinion about whether the functionality proposed here
is worth the trouble, but I do have
On Mon, Sep 27, 2010 at 2:50 AM, SAKAMOTO Masahiko
wrote:
> http://wiki.postgresql.org/wiki/SQL/MED
With regard to what is written here, it strikes me that it would be an
extremely bad idea to try to mix reloptions or attoptions with
fdwoptions. fdwoptions are options to be passed transparently
On Mon, Sep 27, 2010 at 2:50 AM, SAKAMOTO Masahiko
wrote:
> http://wiki.postgresql.org/wiki/SQL/MED
With regard to what is written here, it strikes me that it would be an
extremely bad idea to try to mix reloptions or attoptions with
fdwoptions. fdwoptions are options to be passed transparently
Magnus Hagander escreveu:
> We might, however, want to add a specific section to the
> *documentation* about building extensions on Windows.
>
+1.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Tue, Sep 28, 2010 at 12:46 AM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 5:02 PM, Magnus Hagander wrote:
>> On Mon, Sep 27, 2010 at 08:34, Fujii Masao wrote:
>>> On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova
>>> wrote:
Maybe i'm missing something but this would be a problem if we
It would crash if input is of unrecognized format. Probably than
there's going to be more problems to be concerned with, but just in
case, don't crash in
--
GJ
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index 363fd3c..48ee55d 100644
--- a/src/backend/utils/adt/
On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut wrote:
> On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
>> On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
>> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
>> >> The src/include/catalog/duplicate_oids script reports that 3037 ~
>>
> 2010/9/28 Itagaki Takahiro :
>> On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule
>> wrote:
>>> I looked on some constructs that helps with iteration over array in
>>> plpgsql. I propose a following syntax:
>>>
>>> FOR var IN [array variable | array expression]
>>
>> What is the benefits compared
On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
> On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
> > On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> >> The src/include/catalog/duplicate_oids script reports that 3037 ~
> >> 3040 are used two or more times.
> >>
> >> Though all regres
On Tue, Sep 28, 2010 at 13:50, Robert Haas wrote:
> On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> wrote:
>> On Mon, 27 Sep 2010 21:07:33 -0400
>> Robert Haas wrote:
>>> I found and fixed a few more issues and committed this. The pg_dump
>>> support had a few escaping bugs, and I added tab c
On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
wrote:
> On Mon, 27 Sep 2010 21:07:33 -0400
> Robert Haas wrote:
>> I found and fixed a few more issues and committed this. The pg_dump
>> support had a few escaping bugs, and I added tab completion support
>> for psql. Considering the size of the
Dimitri Fontaine writes:
> Tom Lane writes:
>> Author: Tom Lane
>> Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +
>> Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +
>> Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +000
On Sep 28, 2010, at 10:15 AM, Markus Wanner wrote:
> Hi,
>
> On 09/28/2010 07:24 AM, Li Jie wrote:
>> I'm interested in this parallel project,
>> http://wiki.postgresql.org/wiki/Parallel_Query_Execution
>>
>> But I can't find any discussion and current progress in the website, it
>> seems to sto
2010/9/28 Itagaki Takahiro :
> On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule
> wrote:
>> I looked on some constructs that helps with iteration over array in
>> plpgsql. I propose a following syntax:
>>
>> FOR var IN [array variable | array expression]
>
> What is the benefits compared with
> FOR
On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule wrote:
> I looked on some constructs that helps with iteration over array in
> plpgsql. I propose a following syntax:
>
> FOR var IN [array variable | array expression]
What is the benefits compared with
FOR ... IN SELECT unnest(array) or generate_su
On Tue, Sep 28, 2010 at 09:26, Itagaki Takahiro
wrote:
> On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane wrote:
>>> As I mentioned, we don't need the marks in our build environment at all.
>>
>> In that case, anybody who does need it should fix their build
>> environment.
>>
>> I grow really weary of t
On 28/09/10 11:09, Itagaki Takahiro wrote:
> On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas wrote:
>>> Since we have PGDLLEXPORT in 9.0, we can mark some of exported
>>> functions with it in tutorial codes and maybe contrib modules.
>>
>> If that (a) works and (b) reduces user confusion, +1 from me.
On Tue, Sep 28, 2010 at 06:25, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 9:07 PM, Magnus Hagander wrote:
>> As has been previously mentioned a couple of times, it should be
>> perfectly possible to use streaming replication to get around the
>> limitations of archive_command/archive_timeout to
Hi,
On 09/28/2010 07:24 AM, Li Jie wrote:
> I'm interested in this parallel project,
> http://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> But I can't find any discussion and current progress in the website, it
> seems to stop for nearly a year?
Yeah, I don't know of anybody really work
On Mon, 27 Sep 2010 21:07:33 -0400
Robert Haas wrote:
> I found and fixed a few more issues and committed this. The pg_dump
> support had a few escaping bugs, and I added tab completion support
> for psql. Considering the size of the patch, it seems likely that
> there are some issues we both ov
On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane wrote:
>> As I mentioned, we don't need the marks in our build environment at all.
>
> In that case, anybody who does need it should fix their build
> environment.
>
> I grow really weary of the idea that we should submit to arbitrary
> amounts of uglifica
Hi all,
I'm interested in this parallel project,
http://wiki.postgresql.org/wiki/Parallel_Query_Execution
But I can't find any discussion and current progress in the website, it
seems to stop for nearly a year?
Thanks,
Li Jie
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
86 matches
Mail list logo
