Tom Lane wrote:
(1) modify PGAC_CHECK_READLINE so that it really does prefer readline
over libedit consistently. I think all this would take is switching
the loop order:
for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in -ltermcap -lncurses -lcurses ; do
but possibly I'm
Still running Postgresql 8.0 beta1 from the binary MSI Installer,
Windows XP Professional now Sevice Pack 2
Stopped the running service, started Postgresql from the command line
to get some debugging output:
C:\Programme\PostgreSQL\8.0-beta1\binpostmaster.exe -i
WARNING: could not find a match
Hello.
I found a bug in the behaviour of plpgsql error handling system
while trying to handle foreign key violation exception.
When this error occured, control doesn't jump to exception handling block.
It moves to the next statement instead. When control leaves the
function exception is occured.
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) fix the readline header selection so that it will only take the
headers that correspond to the selected library.
That sounds like a pretty hard problem to solve.
It didn't seem that bad to me. One problem is to not select, eg,
Michael Fuhr [EMAIL PROTECTED] writes:
There is, however, an ownership problem with restoring sequences
in 8.0.0beta. In 7.4.5, for example, pg_dump issues a SET SESSION
AUTHORIZATION command and then creates a table, so implicitly-created
sequences are restored with the correct ownership.
On Sun, 5 Sep 2004 [EMAIL PROTECTED] wrote:
I found a bug in the behaviour of plpgsql error handling system
while trying to handle foreign key violation exception.
When this error occured, control doesn't jump to exception handling block.
It moves to the next statement instead. When control
[EMAIL PROTECTED] writes:
I found a bug in the behaviour of plpgsql error handling system
while trying to handle foreign key violation exception.
This is not a bug in the exception system.
The problem is that FK constraints are enforced by triggers that do not
fire until the end of the outer
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I found a bug in the behaviour of plpgsql error handling system
while trying to handle foreign key violation exception.
This is not a bug in the exception system.
The problem is that FK constraints are enforced by triggers that do not
fire until
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
However, of course the best thing is to just fix it, which I guess I'll
have a crack at...
Given that pg_dump does put out GRANT/REVOKE operations on the sequence,
it's certainly aware that the sequence exists. I suspect this is just a
fixable
