Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
I just took a look at adding gssapi build support on solaris (solaris
10/x86_64, sun studio 10, 64bit build) which seemed easy enough by
educating configure to look for -lgss but while it compiles just fine
the resulting tree will not be able
Jim C. Nasby wrote:
On Fri, Jul 13, 2007 at 01:45:18PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
According to http://developer.postgresql.org/index.php/Feature_Matrix,
8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
CREATE INDEX CONCURRENTLY
Well, I guess
Jim C. Nasby a écrit :
On Fri, Jul 13, 2007 at 01:45:18PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
According to http://developer.postgresql.org/index.php/Feature_Matrix,
8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
CREATE INDEX CONCURRENTLY
Well, I guess
I just noticed that when the BY option was added to plpgsql FOR loops,
no real error checking was done. If you specify a zero step value,
you'll have an infinite loop. If you specify a negative value, the
loop variable will increment in the wrong direction until integer
overflow occurs. Neither
Tom Lane wrote:
I just noticed that when the BY option was added to plpgsql FOR
loops, no real error checking was done. If you specify a zero step
value, you'll have an infinite loop. If you specify a negative
value, the loop variable will increment in the wrong direction
until integer
I have just absorbed the significance of some code that has been in
plpgsql since day one, but has never been documented anyplace.
It seems that if you attach a label to a statement block in a
plpgsql function, you can do more with the label than just use it in
an EXIT statement (as I'd always
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I just noticed that when the BY option was added to plpgsql FOR
loops, no real error checking was done. If you specify a zero step
value, you'll have an infinite loop. If you specify a negative
value, the loop variable will
Tom Lane wrote:
Anyway, I'm not writing just to point out that we have a previously
undocumented feature. I notice that the section on porting from Oracle
PL/SQL mentions
You cannot use parameter names that are the same as columns that are
referenced in the function. Oracle allows you
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I just noticed that when the BY option was added to plpgsql FOR
loops, no real error checking was done. If you specify a zero step
value, you'll have an infinite loop. If you specify a negative
value, the
Heikki Linnakangas [EMAIL PROTECTED] writes:
ISTM supporting somefunc.ambiguous just gives us another way to
reference the parameter, and there still isn't any way to refer the column.
Sure. All this will do is let us remove a noted incompatibility with
Oracle, which seems worth doing if it's
ISTM supporting somefunc.ambiguous just gives us another way to
reference the parameter, and there still isn't any way to refer the
column.
Could we not, at least, support explicit column disambiguation?
e.g. This PL/SQL procedure:
CREATE OR REPLACE PROCEDURE insert_emp (empno
Affan Salman [EMAIL PROTECTED] writes:
Could we not, at least, support explicit column disambiguation?
The problem is that there are places in the SQL grammar where we don't
allow qualification of a SQL name --- INSERT column lists, UPDATE SET
targets, and SELECT AS labels are three I can think
Andrew Dunstan [EMAIL PROTECTED] writes:
I suspect we have a significant incompatibility with PLSQL in this area.
Ugh. Google seems to confirm your thought that Oracle expects
FOR i IN REVERSE 1..10 LOOP
which is not the way we are doing it. Not sure if it's worth trying to
fix this ---
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I suspect we have a significant incompatibility with PLSQL in this area.
Ugh. Google seems to confirm your thought that Oracle expects
FOR i IN REVERSE 1..10 LOOP
which is not the way we are doing it. Not sure
On Fri, Jul 13, 2007 at 03:29:16PM +0100, Gregory Stark wrote:
The key to the algorithm is that it uses a trie to bin rows with common
leading prefixes together. This avoids performing redundant comparisons
between those columns later.
Sounds like a variation on the idea suggested before,
Hello,
We ran into a problem with a customer this weekend. They had 128,000
tables and we were trying to run a pg_dump. When we reached
max_locks_per_transaction, the dump just hung waiting to lock the next
table.
Would it make sense to have some sort of timeout for that?
Joshua D. Drake [EMAIL PROTECTED] writes:
We ran into a problem with a customer this weekend. They had 128,000
tables and we were trying to run a pg_dump. When we reached
max_locks_per_transaction, the dump just hung waiting to lock the next
table.
Would it make sense to have some sort of
Recently I ran into an issue where restoring from pg_dump from one machine
to another with non-matching tablespaces. The primary issue is that index
creation will fail if the tablespace does not exist from the dump. I was
thinking to best solution for this would be a pg_dump option such as
Gavin M. Roy [EMAIL PROTECTED] writes:
Recently I ran into an issue where restoring from pg_dump from one machine
to another with non-matching tablespaces. The primary issue is that index
creation will fail if the tablespace does not exist from the dump. I was
thinking to best solution for
Anyway, I'm not writing just to point out that we have a previously
undocumented feature. I notice that the section on porting from Oracle
PL/SQL mentions
You cannot use parameter names that are the same as columns that are
referenced in the function. Oracle allows you to do this if you
In at least those three cases, we know that it's not sensible to
substitute a parameter. If that's true in all the problem cases,
which seems likely, then we could do something with Greg's idea
of using the raw parse tree from the main SQL parser to guide
decisions about where parameters may be
21 matches
Mail list logo
