From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Dave Page <dpage(at)postgresql(dot)org> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, 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 12:16:24 |
Message-ID: | 46F7AA98.2090805@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
src/bin/psql/common.c has a routine that lets psql get round this, by
not sending a BEGIN in the case of the offending statements. I have no
idea if this might be helpful for pgadmin though.
cheers
andrew
Dave Page wrote:
> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-09-24 12:38:11 | Re: LIKE wildcards escaping problem |
Previous Message | Thea | 2007-09-24 12:09:54 | LIKE wildcards escaping problem |