Peter Eisentraut wrote:
Am Thursday, 17. July 2008 schrieb Bruce Momjian:
Anyways the thing that struck me as odd was the messages appearing
*before* the header. It seems to me the header should print followed by
.psqlrc output followed by normal output.
Do you like this better?
Am Sunday, 20. July 2008 schrieb Tom Lane:
* This disables AC_TRY_RUN tests, of course. The only adverse
consequence I noticed was failure to recognize that
-Wl,-dead_strip_dylibs is applicable, which is marginally annoying but
hardly fatal.
On the whole I still wouldn't trust
Peter Eisentraut [EMAIL PROTECTED] writes:
For example, I'm a bit curious on the following aspect. This program should
fail to compile on 32-bit platforms but succeed on 64-bit:
#include stddef.h
struct s { char a; long b; };
int main(int argc, char *argv[])
{
int
Tom Lane wrote:
What PG version are you testing? Maybe you need to show a complete
test case, instead of leaving us to guess at details?
I think that example is bogus. Let's forget that one, and look at the
attached script.
The underlying problem is that when we do GetOverrideSearchPath()
This crashes the backend:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n 5 ORDER BY 1
)
SELECT n FROM t;
apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES (1) UNION
Heikki Linnakangas [EMAIL PROTECTED] writes:
The underlying problem is that when we do GetOverrideSearchPath() in
CreateCachedPlan, the memorized search path doesn't include pg_temp, if
the temp namespace wasn't initialized for the backend yet. When we later
need to revalidate the plan,
Tatsuo Ishii [EMAIL PROTECTED] writes:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Folks,
It's been 3 weeks since the start of the commitfest, and less than half
the patches have been committed or sent back. We seem to be stalled.
What's going on?
Looking at the wiki, I see some issues:
Robert Lor, Jaime Casanova, Mark Woodward, Heikki Linnakangas Zoltan
Boszormenyi
On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote:
Folks,
It's been 3 weeks since the start of the commitfest, and less than half
the patches have been committed or sent back. We seem to be stalled.
What's going on?
So, what do we need to do to get this moving?
Let's not forget
Joshua D. Drake [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote:
It's been 3 weeks since the start of the commitfest, and less than half
the patches have been committed or sent back. We seem to be stalled.
Let's not forget that it is the middle of summer. As
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Sun, 2008-07-20 at 10:17 -0700, Josh Berkus wrote:
It's been 3 weeks since the start of the commitfest, and less than half
the patches have been committed or sent back. We seem to be stalled.
libpq object hooks, now called
Andrew,
Do we need to add this patch to the sept commitfest? How would we
remove it from the current one?
Done.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
standard. For example,
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
Thus I think we should avoid this kind of ORDER BY. Probably we should
avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by
I was trying to sort out the problem with not creating new catalog for
character sets and I came up following ideas. Correct me if my ideas are
wrong.
Since collation has to have a defined character set I'm suggesting to use
already written infrastructure of encodings and to use list of encodings
hi all,
I read the code that it seems easy for the cursor in plpgsql to return
ROW_COUNT after
MOVE LAST etc. The SPI_processed variable already there, but didn't put
it into estate
structure, any reason for that?
thanks and best regards
-laser
--
Sent via pgsql-hackers mailing list
Bruce Momjian [EMAIL PROTECTED] writes:
Wow. I adjusted the patch slightly and applied it; the updated version
is attached. We have been waiting for this to be done for quite some
time. Thanks.
Hmm ... I don't think that this patch actually addresses the TODO item.
The TODO item seems to
18 matches
Mail list logo
