Re: CREATE DATABASE cannot be executed from a function or multi-command string

From: Dave Page <dpage(at)postgresql(dot)org>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE DATABASE cannot be executed from a function or multi-command string
Date: 2007-09-24 10:45:13
Message-ID: 46F79539.8030809@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> Dave Page wrote:
>> I get the above error message when creating a database in pgAdmin now:
>>
>> CREATE DATABASE demo
>> WITH ENCODING='SQL_ASCII'
>> TABLESPACE=pg_default;
>> COMMENT ON DATABASE demo IS 'This is the demo database';
>> GRANT ALL ON DATABASE demo TO public;
>> ALTER DATABASE demo SET search_path=demo;
>>
>> I understand what the message is telling me to do, but what is the
>> reason for this change, and is it really *required*?
>
> This is the commit that changed it:
>
> http://archives.postgresql.org/pgsql-committers/2007-03/msg00270.php
>
> It was in fact never supposed to work, but we failed to detect it. I had
> to modify my test scripts that did something like psql -c "VACUUM foo;
> SELECT ..." because of that as well. It's highly likely that it'll brake
> other people's scripts as well, but I don't think there's much we can do
> about it :(.

Yeah, I found that just after I mailed.

>> The way pgAdmin is
>> designed, a change to accomodate firing everything off in seperate
>> queries would be a significant one which would most likely require us to
>> effectively restart our whole beta process and may well mean we don't
>> have a release ready for 8.3 in fact :-(
>
> I'm surprised this hasn't been noticed before, the change was made back
> in March. Are you sure there's more queries like that that need to be
> modified?

It's not the query, but the way it's passed around in internally from
the dialogue to the code the executes it and updates the browser. It all
assumes every update is a single atomic statement - and in fact relies
on that assumption in a number of classes. After thinking about it some
more I may have a less-invasive solution in which we embed a marker in
the SQL generated to denote that the statement should be split at that
point and executed as a seperate block - but it seems somewhat hacky for
my tastes :-(

I agree that this is likely to break a lot of folks scripts.

Regards, Dave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-09-24 10:51:30 Re: GUC variable renaming, redux
Previous Message Heikki Linnakangas 2007-09-24 10:34:23 Re: [COMMITTERS] pgsql: Reduce the size ofmemoryallocations by lazy vacuum when