G'day all,
PG version: 8.1.4 (also 7.4.13)
OS: Linux (debian/testing)
In an update, using a sub-select from a table with the same name
but in a different schema results in an error. The same thing
works if you alias the sub-select table or if you qualify the
schema of the update table.
See scr
G'day all,
PG version: 7.4.7(debian 7.4.7-6sarge2)
OS: Linux (debian sarge)
I started a 'vacuum full analyze' using pgsql, then, after
about 10 minutes, I issued a control-c in pgsql. This hadn't
returned my prompt after another 10 minutes or so. A glance at
the backend showed other process
G'day all,
PG version: 8.1.0 (also 7.4.9)
OS: Linux (debian/testing)
Restoring a database with inherited tables can result in an
incorrect schema (and therefore inability to restore data).
E.g. using the script below, the 'bar.f1' column in the 'new'
database ends up with a 'not null' constrain
On Wed, Feb 22, 2006 at 10:11:51AM -0500, Tom Lane wrote:
> Chris Dunlop <[EMAIL PROTECTED]> writes:
>> E.g. using the script below, the 'bar.f1' column in the 'new'
>> database ends up with a 'not null' constraint that isn't present
>>
