I am looking into the SQL standard to try to determine precisely how the
CTE feature should behave.
Taking a simple case like:
with recursive
foo(i) as
(values(1)
union all
select i+1 from foo where i 5)
select * from foo;
And looking at the SQL standard 200n 7.13:
On Sun, Sep 7, 2008 at 9:52 PM, Tom Lane [EMAIL PROTECTED] wrote:
Whilst going through the pending patch to add TRUNCATE as a separate
permission, I noticed that it neglected to add TRUNCATE to the various
columns in information_schema that display privileges. I wonder whether
we should do
David Rowley wrote:
Thanks for all the reviews and suggestions.
David, could you re-run the performance tests you ran earlier? I'm
curious to know what impact switching to the simpler loop for 1-byte
pattern had.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
Martin Pihlak wrote:
Magnus Hagander wrote:
I wrote a patch for this some time back, that was actually applied.
Turns out it didn't work, and I ran out of time to fix it, so it was
backed out again. And then I forgot about it :-) If you look through the
cvs history of pgstat you should be
Tom Lane wrote:
Martin Pihlak [EMAIL PROTECTED] writes:
I had also previously experimented with stat() based polling but ran into
the same issues - no portable high resolution timestamp on files. I guess
stat() is unusable unless we can live with 1 second update interval for the
stats (eg.
Thanks Shane for your response...
On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
What is a good way to start understanding backend(postgres) code? Is
there any documentation available especially for developers?
Most of the developer info is within comments in the code itself.
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which
Bruce Momjian napsal(a):
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
Keep in a mind that there are more kind of pages. Heap is easy, but each index
AM has own specific :(. Better
Bruce Momjian napsal(a):
Heikki Linnakangas wrote:
Bruce Momjian wrote:
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
VACUUM?
Having to run a manual command defeats the purpose
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Im just following this:
http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
Hi Alex. Thanks for taking the time to review my patch.
Feature test: Everything seems to work as advertised. However before
Heikki Linnakangas napsal(a):
Tom Lane wrote:
I didn't see anything that looked like an immediate change in user table
contents, unless they used the name type; but what of relation forks?
Relation forks didn't change anything inside relation files, so no
scanning of relations is required
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you inject old data file after catalog upgrade,
Hitoshi Harada [EMAIL PROTECTED] wrote:
so I guess all of these variables should be defined together but
actually you put the two in buffile.h while the others in
buf_internals.h. Is there clear reason for that?
That's because buffile.c includes buffile.h, but not buf_internals.h .
Here is a revised version of the pgbench duration patch.
I merged some comments from Brendan and gnari.
Brendan Jurd [EMAIL PROTECTED] wrote:
Wouldn't this be better written as:
if ((duration 0 timer_exceeded) || st-cnt = nxacts)
sorry, but these do not lok as the same thing to me.
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, set enable_indexscan =off or set
enable_sort=off ought to work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On Wed, 2008-09-03 at 11:58 +0300, Asko Oja wrote:
On Wed, Sep 3, 2008 at 11:20 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On 9/2/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
On Mon, 2008-09-08 at 13:52 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, set enable_indexscan =off or set
enable_sort=off ought to work.
Agreed - as long as that is
Markus Wanner [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
Are there any better idea to share one socket connection between
backends (and bgwriter)?
I fear I'm repeating myself, but I've had the same problem for
Postgres-R and solved it with an internal message passing
Hi,
On Sun, 2008-09-07 at 13:39 -0400, Andrew Dunstan wrote:
The point I was making is that for 8.4, unless you specifically
configure with --disable-integer-datetimes, it is enabled by default on
any platform that can support it. We committed that change on 30 March
here:
Hi,
ITAGAKI Takahiro wrote:
1. Is process-switching approach the best way to share one socket?
Both Postgres-R and the log-shipping prototype use the approach now.
Can I think there is no objection here?
I don't see any appealing alternative. The postmaster certainly
Heikki Linnakangas [EMAIL PROTECTED] writes:
The bpchar_pattern_ops change you mentioned must be this one:
A not-immediately-obvious incompatibility is that the sort order within
bpchar_pattern_ops indexes changes --- it had been identical to plain
strcmp, but is now
Simon Riggs [EMAIL PROTECTED] writes:
Peter's objection is reasonable, as far as most people have replied.
Marko's proposal is also reasonable to most people, since they do not
wish fat fingers to cause any amount of downtime. ISTM that if you've
done this, you appreciate the feature, if not
Zdenek Kotala [EMAIL PROTECTED] writes:
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
I don't think that'd be real
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd also be worried about issues like clock skew between the
postmaster's time and the filesystem's time.
Can that even happen on a local filesystem? I guess you could put the
file on NFS though, but that seems to be.. eh.
M2Y [EMAIL PROTECTED] writes:
On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
Most of the developer info is within comments in the code itself.
Another place to start ishttp://www.postgresql.org/developer/coding
I have seen this link. But, I am looking(or hoping) for any design
Heikki Linnakangas [EMAIL PROTECTED] writes:
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, set enable_indexscan =off or set enable_sort=off
ought to work.
Yeah, I've been thinking about how to use the planner
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but AFAICS
nothing that
Gregory Stark [EMAIL PROTECTED] writes:
Yeah, I've been thinking about how to use the planner to do this.
I thought the answer to that was going to be more or less call
cost_sort() and cost_index() and compare the answers.
To do that it seems to me what we would need to do is add a function
Hi,
ITAGAKI Takahiro wrote:
Are there any better idea to share one socket connection between
backends (and bgwriter)? The connections could be established after
fork() from postmaster, and number of them could be two or more.
This is one of the most complicated part of synchronous log shipping.
Simon Riggs [EMAIL PROTECTED] writes:
Peter's objection is reasonable, as far as most people have replied.
Marko's proposal is also reasonable to most people, since they do not
wish fat fingers to cause any amount of downtime. ISTM that if you've
done this, you appreciate the feature, if not
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release
to implement upgrade-in-place. There's
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd also be worried about issues like clock skew between the
postmaster's time and the filesystem's time.
Can that even happen on a local filesystem? I guess you could put the
file on NFS though, but that seems to
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you inject old
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but
Bruce Momjian [EMAIL PROTECTED] wrote:
b) Use new background process as WALSender
This idea needs background-process hook which enables users
to define new background processes
I think starting/stopping a process for each WAL send is too much
overhead.
Yes, of course slow.
Gregory Stark [EMAIL PROTECTED] writes:
I'm all for using the correct acronyms in all messages and documentation. What
I find annoying is the:
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
But of course case insensitivity isn't going to fix that example for
M2Y escribió:
On Sep 7, 11:52 pm, [EMAIL PROTECTED] (Shane Ambler) wrote:
What is a good way to start understanding backend(postgres) code? Is
there any documentation available especially for developers?
What is commit log and why it is needed?
To achieve ACID (Atomic, Consistent,
Tom Lane wrote:
Timestamp within the file is certainly better than trying to rely on
filesystem timestamps. I doubt 1 sec resolution is good enough, and
I'd also be worried about issues like clock skew between the
postmaster's time and the filesystem's time.
Attached is a patch which adds
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where we should draw the line in
trying to accept variant input.
Well it's not a perfect precedent but for example,
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Sep 08, 2008 at 02:18:55PM +0100, Greg Stark wrote:
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where
On Mon, Sep 8, 2008 at 8:44 PM, Markus Wanner [EMAIL PROTECTED] wrote:
Merge into WAL writer?
Uh.. that would mean you'd loose parallelism between WAL writing to disk and
WAL shipping via network. That does not sound appealing to me.
That depends on the order of WAL writing and WAL
Martin Pihlak [EMAIL PROTECTED] writes:
Attached is a patch which adds a timestamp to pgstat.stat file header,
backend_read_statsfile uses this to determine if the file is fresh.
During the wait loop, the stats request message is retransmitted to
compensate for possible loss of message(s).
Greg Stark [EMAIL PROTECTED] writes:
On Mon, Sep 8, 2008 at 2:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
But of course case insensitivity isn't going to fix that example for you.
So we're right back at the question of where we should draw the line in
trying to accept variant input.
Well it's
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if
Greg Sabino Mullane wrote:
Tom Lane wrote:
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if not there already?
alvherre=# set work_mem = '1g';
ERROR: invalid value for parameter
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT listing all
valid inputs, if not
Gregory Stark wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
postgres=# set work_mem = '1g';
ERROR: invalid value for parameter work_mem: 1g
Perhaps this would be a great place for a HINT
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
For what guc would you find a unit of posix-style blocks relevant?!
--
Gregory Stark [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
For what guc would you find a unit of
Hi,
Fujii Masao wrote:
1. A backend writes WAL to disk.
2. The backend wakes up WAL sender process and sleeps.
3. WAL sender process does WAL shipping and wakes up the backend.
4. The backend issues sync command.
Right, that would work. But still, the WAL writer process would block
during
These are my initial comments about the Common Table Expressions (CTE)
patch, also known as WITH [RECURSIVE]. These comments are based on the
patch here:
http://archives.postgresql.org/pgsql-patches/2008-08/msg00021.php
This is a semantically complex feature, and the standard is fairly
complex
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
It's good as a joke, but what if the user says '1024b'? Does it mean
1024 blocks or one kilobyte? If blocks, what size are we talking, the
usual 512 bytes, or our BLCKSZ?
I've got a case where I need to reverse strings, and find that, oddly
enough, there isn't a C-based reverse() function.
A search turns up pl/pgsql and SQL implementations:
create or replace function reverse_string(text) returns text as $$
DECLARE
reversed_string text;
incoming alias for $1;
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote:
I've got a case where I need to reverse strings, and find that, oddly
enough, there isn't a C-based reverse() function.
A search turns up pl/pgsql and SQL implementations:
just for completenes - there is also pl/perl and c versions
Hello
2008/9/8 Mario Weilguni [EMAIL PROTECTED]:
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
it isn't problem, but I am
Mario Weilguni wrote:
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
Yes, quite.
Perl's reverse might work with
On Mon, 2008-09-08 at 11:57 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
So thinking we should test XLogArchiveCheckDone() for both
stopxlogfilename and history file and then stat for the stop WAL file:
This seems better.
Somehow I missed the 5-Apr patch that
2008/9/8 Andrew Dunstan [EMAIL PROTECTED]:
Mario Weilguni wrote:
(Aside: presumably we could walk thru the string destructively,
in-place, swapping bytes; I think that would be theoretically
quickest...)
Hmmm... I guess it will not work für UTF-8 or any other multibyte charset
Yes,
Hello
I found one usefull article
http://iablog.sybase.com/paulley/2008/07/sql2008-now-an-approved-iso-international-standard/
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Simon Riggs [EMAIL PROTECTED] writes:
You sound like you're in the middle of doing this yourself. Or would you
like me to do that?
Yeah, done and committed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Pavel Stehule escribió:
Hello
I found one usefull article
http://iablog.sybase.com/paulley/2008/07/sql2008-now-an-approved-iso-international-standard/
Wow, this is really horrid:
# F856 through F859: FETCH FIRST clause in subqueries, views,
and query expressions. The
Alvaro == Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Wow, this is really horrid:
Alvaro # F856 through F859: FETCH FIRST clause in subqueries,
Alvaro views, and query expressions. The SQL:2008 syntax for
Alvaro restricting the rows of a result set is FETCH FIRST, rather
Alvaro
Jeff == Jeff Davis [EMAIL PROTECTED] writes:
Jeff * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
If more than one common table expression is defined in the same
statement, cyclic references between the common table expressions are
On Mon, Sep 8, 2008 at 6:24 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Code review: one minor nit
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
***
*** 781,787 static
On Mon, Sep 8, 2008 at 6:59 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is a revised version of the pgbench duration patch.
I merged some comments from Brendan and gnari.
The changes look good. I tried out the new v3 patch and didn't
encounter any problems.
One last minor quibble - I
Simon Riggs [EMAIL PROTECTED] writes:
So thinking we should test XLogArchiveCheckDone() for both
stopxlogfilename and history file and then stat for the stop WAL file:
This seems better.
Somehow I missed the 5-Apr patch that introduced this bogosity.
Next time you make a fundamental change in
On Mon, 2008-09-08 at 19:19 +0900, ITAGAKI Takahiro wrote:
Bruce Momjian [EMAIL PROTECTED] wrote:
b) Use new background process as WALSender
This idea needs background-process hook which enables users
to define new background processes
I think starting/stopping a
Settings in postgresql.conf are currently case-insensitive. Except
for the units.
And, of course, filenames when you are using a case-sensitive
filesystem. Because these are things that are defined by some
convention other than the ones the PGDG made up. Since units fall
into that category,
Heikki Linnakangas wrote:
David Rowley wrote:
Thanks for all the reviews and suggestions.
David, could you re-run the performance tests you ran earlier? I'm
curious to know what impact switching to the simpler loop for 1-byte
pattern had.
Sure:
[EMAIL PROTECTED] (hubert depesz lubaczewski) writes:
On Mon, Sep 08, 2008 at 11:20:18AM -0400, Chris Browne wrote:
I've got a case where I need to reverse strings, and find that, oddly
enough, there isn't a C-based reverse() function.
A search turns up pl/pgsql and SQL implementations:
just
I've been looking at
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
and am not very happy with it. One big problem is that it has the
parser collecting the list of functions referenced by a plan, which
is quite bogus --- consider functions introduced into the tree during
rewrite, or
Jeff Davis [EMAIL PROTECTED] writes:
* Mutual Recursion:
with recursive
foo(i) as (values(1) union all select i+1 from bar where i 10),
bar(i) as (values(1) union all select i+1 from foo where i 10)
select * from foo;
ERROR: mutual recursive call is not supported
The
On Mon, 2008-09-08 at 21:13 +0100, Gregory Stark wrote:
Jeff Davis [EMAIL PROTECTED] writes:
* Mutual Recursion:
with recursive
foo(i) as (values(1) union all select i+1 from bar where i 10),
bar(i) as (values(1) union all select i+1 from foo where i 10)
select * from
On Mon, 2008-09-08 at 18:08 +0100, Andrew Gierth wrote:
Jeff * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
As with some other things in my list, this doesn't need to be supported
in 8.4. I just wanted to lay out my
Tom Lane wrote:
Hmm. With the timestamp in the file, ISTM that we could put all the
intelligence on the reader side. Reader checks file, sends message if
... snip ...
remember the file timestamp it last wrote out. There are various ways
you could design it but what comes to mind here is for
Fujii Masao wrote:
On Mon, Sep 8, 2008 at 8:44 PM, Markus Wanner [EMAIL PROTECTED] wrote:
Merge into WAL writer?
Uh.. that would mean you'd loose parallelism between WAL writing to disk and
WAL shipping via network. That does not sound appealing to me.
That depends on the order
Jeff == Jeff Davis [EMAIL PROTECTED] writes:
Jeff Aggregates should be blocked according to the standard.
Jeff Also, causes an infinite loop. This should be fixed for 8.4.
Does the standard require anywhere that non-conforming statements
must be diagnosed? (seems impractical, since it
On Mon, 2008-09-08 at 22:53 +0100, Andrew Gierth wrote:
Yes, you've misinterpreted. When the spec says that a query shall
not do such-and-such, it means that a conforming client isn't allowed
to do that, it does NOT mean that the server is required to produce an
error when it sees it.
Zdenek Kotala wrote:
You mentioned data types, but it is not a problem. You can easily extend data
type attribute about version information and call correct in/out functions.
Or
use different Oid for new data type version. There are more possible easy
solutions for data types. And for
Alvaro Herrera wrote:
So I just noticed that we have a description of the Pg innards in the
sourcecode, complete with a flowchart and all, at src/tools/backend.
I had already seen this graph years ago; what shocked me the most was
finding out that there's a pointer to it in the Developer's
Hi,
Bruce Momjian wrote:
Backends would
update a shared memory variable specifying how far they want the wal
streamer to advance and send a signal to the wal streamer if necessary.
Backends would monitor another shared memory variable that specifies how
far the wal streamer has advanced.
Markus Wanner wrote:
Hi,
Bruce Momjian wrote:
Backends would
update a shared memory variable specifying how far they want the wal
streamer to advance and send a signal to the wal streamer if necessary.
Backends would monitor another shared memory variable that specifies how
far the
Martin Pihlak escribió:
Tom Lane wrote:
Hmm. With the timestamp in the file, ISTM that we could put all the
intelligence on the reader side. Reader checks file, sends message if
Attached is a patch that implements the described signalling.
Are we keeping the idea that the reader sends a
Volkan YAZICI wrote:
On Fri, 05 Sep 2008, Tom Lane [EMAIL PROTECTED] writes:
at the call sites, and then
errmsg(%s, _(msg))
when throwing the error.
Modified as you suggested. BTW, will there be a similar i18n scenario
for dropped column you mentioned below?
Yes, you need _()
Jeff == Jeff Davis [EMAIL PROTECTED] writes:
Jeff I am looking into the SQL standard to try to determine
Jeff precisely how the CTE feature should behave.
Jeff Taking a simple case like:
Jeff with recursive
Jeff foo(i) as
Jeff (values(1)
Jeff union all
Jeff
Andrew Gierth wrote:
Alvaro This means we have to support stuff like
Alvaro declare foo cursor for select * from lists;
Alvaro select * from (fetch first from foo) as bar;
No, that's wrong.
[...]
so it's like this:
select * from foo order by bar offset 5 rows fetch first 10 rows
Alvaro == Alvaro Herrera [EMAIL PROTECTED] writes:
so it's like this:
select * from foo order by bar offset 5 rows fetch first 10 rows only;
Alvaro Oh, I see -- it's just a cumbersome way to have our LIMIT
Alvaro clause. What's the ONLY for?
It seems to be just a mandatory noise
Greetings,
I've reviewed the patch here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
and am happy to report that it looks to be in good order. It has
documentation and regression updates, is in context diff format,
patches against current CVS with only some minor fuzz,
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
because the location is saved as reset location and restored when the
variable is reset. It worked fine in all cases I tested.
Hmm. Actually,
Marko Kreen wrote:
Thirdly, please don't use standard units argument, unless you plan to
propose use of KiB, MiB, GiB at the same moment.
In defense of standard units, if the postgres docs say
Postgres will round up to the nearest power of 2
kB and MB seem very clear to me. If we want to
On Mon, 8 Sep 2008 10:32:40 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
My vote is to reject the patch and work on a config checker.
+1
+1
Joshua D. Drake
--
The PostgreSQL Company since
On Tue, 2008-09-09 at 01:45 +0100, Andrew Gierth wrote:
The contains language in the spec is tricky. And I think there's some
issue here with the spec confusing query expression and query
expression body; some of the language refers to If a query expression
AQEk not marked as recursive is
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
These are my initial comments
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
These are my initial comments
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
The standard specifies that non-recursive WITH should be evaluated
once.
What
On Mon, 8 Sep 2008, Alvaro Herrera wrote:
(I dropped the default stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
I have multiple GUC-related projects that are all stalled waiting for that
capability to be added. The only thing there wasn't clear consensus
Hi,
I looked some comment for the synchronous replication and understood
the consensus of the community was that the sync replication should be
added using not hooks and plug-ins but core-patches. If my understanding
is right, I will change my development plan so that the sync replication
may be
99 matches
Mail list logo
