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
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 qua
"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 solutio
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
--ign
"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 som
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?
wait_for_lock_tim
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, wh
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
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 -
"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 th
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 emp.e
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
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 l
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
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 wil
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 su
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 intege
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. Neithe
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 it
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,
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 b
21 matches
Mail list logo
