Hello
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
..
END LOOP
var - declared variable - theoretically we can a detect var type from
array type, but it needs a early expression an
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas robertmh...@gmail.com wrote:
Oh - I didn't realize this meant marking lots of things in contrib
that didn't otherwise need to be marked. Â Why do other people need
this if we don't?
As I
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
On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, 27 Sep 2010 21:07:33 -0400
Robert Haas robertmh...@gmail.com 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
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 working
On Tue, Sep 28, 2010 at 06:25, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 9:07 PM, Magnus Hagander mag...@hagander.net 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
On 28/09/10 11:09, Itagaki Takahiro wrote:
On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas robertmh...@gmail.com 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,
On Tue, Sep 28, 2010 at 09:26, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule pavel.steh...@gmail.com 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
2010/9/28 Itagaki Takahiro itagaki.takah...@gmail.com:
On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule pavel.steh...@gmail.com
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]
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 stop for nearly
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
Author: Tom Lane t...@sss.pgh.pa.us
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
On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Mon, 27 Sep 2010 21:07:33 -0400
Robert Haas robertmh...@gmail.com 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
On Tue, Sep 28, 2010 at 13:50, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Mon, 27 Sep 2010 21:07:33 -0400
Robert Haas robertmh...@gmail.com wrote:
I found and fixed a few more issues and committed this. The
On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
On Tue, Sep 28, 2010 at 13:50, Robert Haas robertmh...@gmail.com 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
2010/9/28 Itagaki Takahiro itagaki.takah...@gmail.com:
On Tue, Sep 28, 2010 at 3:24 PM, Pavel Stehule pavel.steh...@gmail.com
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]
On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
On Tue, Sep 28, 2010 at 13:50, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
The src/include/catalog/duplicate_oids
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
---
On Tue, Sep 28, 2010 at 12:46 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 5:02 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Sep 27, 2010 at 08:34, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova ja...@2ndquadrant.com
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 Mon, Sep 27, 2010 at 2:50 AM, SAKAMOTO Masahiko
sakamoto.masah...@oss.ntt.co.jp 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
On Mon, Sep 27, 2010 at 2:50 AM, SAKAMOTO Masahiko
sakamoto.masah...@oss.ntt.co.jp 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
Pavel Stehule pavel.steh...@gmail.com 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
On Tue, Sep 28, 2010 at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com 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
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 immensely.
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com 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:
Robert Haas robertmh...@gmail.com 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).
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com 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
On Tue, Sep 28, 2010 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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,
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com 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
2010/9/28 Grzegorz Jaśkiewicz gryz...@gmail.com:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com 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,
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
On Tue, Sep 28, 2010 at 3:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 28, 2010 at 8:03 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-28 at 13:53 +0200, Magnus Hagander wrote:
On Tue, Sep 28, 2010 at 13:50, Robert Haas robertmh...@gmail.com
wrote:
On Tue, Sep
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 that is
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 27, 2010 at 2:09 PM, David Fetter da...@fetter.org 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
On Tue, Sep 28, 2010 at 12:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 27, 2010 at 2:09 PM, David Fetter da...@fetter.org wrote:
I must be missing something pretty crucial here as far as the
complexity of changing all the regression tests.
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
David Fetter da...@fetter.org 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
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
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-party
Peter Eisentraut pete...@gmx.net 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
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 STOP
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
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 used. I don't
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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 -
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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.
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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
On Tue, Sep 28, 2010 at 4:39 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
As an example, is this a for-in-query or a
for-in-array?
FOR v IN (SELECT arraycol
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,
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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
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
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 attached
patch that explains the proper
Sergey Burladyan eshkin...@gmail.com 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 */
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
Tom Lane t...@sss.pgh.pa.us 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
On Tue, Sep 28, 2010 at 6:16 PM, Magnus Hagander mag...@hagander.net 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
On Wed, Sep 29, 2010 at 6:03 AM, David Fetter da...@fetter.org 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
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 Tue, Sep 28, 2010 at 9:11 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Sep 29, 2010 at 6:03 AM, David Fetter da...@fetter.org 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
2010/9/23 Robert Haas robertmh...@gmail.com:
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
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 ...
...
On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com 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
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
Alvaro Herrera alvhe...@commandprompt.com 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
2010/9/28 Robert Haas robertmh...@gmail.com:
2010/9/23 Robert Haas robertmh...@gmail.com:
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
On Tue, Sep 28, 2010 at 9:33 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com 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
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
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
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.
On Thu, Sep 9, 2010 at 8:57 PM, Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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()
On Tue, Sep 28, 2010 at 5:23 PM, Magnus Hagander mag...@hagander.net 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
On Mon, Sep 27, 2010 at 10:05 PM, Itagaki Takahiro
itagaki.takah...@gmail.com 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
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
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/28 Tom Lane t...@sss.pgh.pa.us:
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
On Wed, Sep 29, 2010 at 1:27 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
On Wed, Sep 29, 2010 at 12:53 PM, Josh Kupershmidt schmi...@gmail.com 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
Any updates on this?
On Tue, Sep 21, 2010 at 10:47 PM, Sushant Sinha sushant...@gmail.comwrote:
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
86 matches
Mail list logo
