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
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 (pgsql-
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
> 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 i
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 b
> > 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
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
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
"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 su
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 for
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 and
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 (pgsql-hacker
"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 pl
> 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
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() i
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
> struct s { char a; long b; };
> int main(int argc, char *argv[])
> {
> int array[offseto
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 cross-co
17 matches
Mail list logo
