I have an admin script that drops a schema and then recreates it (quick
way to refresh from backup). However, if the schema doesn't exist, the
drop errors, as you would expect. The next SQL command, the schema
create, is never executed.

I do not have ON_ERROR_STOP set so why is this happening? I don't want
to split down to two calls of psql if possible, which is the present
work-around. Would prefer to solve the problem.

Thanks,

Brad


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Michael Fuhr wrote:

>On Fri, Jan 14, 2005 at 12:03:02PM +0000, Bradley Kieser wrote:
>
>
>
>>I have an admin script that drops a schema and then recreates it (quick
>>way to refresh from backup). However, if the schema doesn't exist, the
>>drop errors, as you would expect. The next SQL command, the schema
>>create, is never executed.
>>
>>
>
>How do you know the create is never executed? Are you looking for
>the schema and not finding it? How are you looking? Or is there
>an error message? What is it?
>
>
Looking for the schema and not finding it.

>Are you doing the drop and create in the same transaction? If so,
>
>
I have auto-commit on.

>then the drop statement's failure is preventing subsequent statements
>in that transaction from executing. If that's not the problem then
>please post a self-contained test case so we can see exactly what
>you're doing.
>
>
Hmm, maybe I need to explicitly call commit? Will try and get back to you.

>
>
>>I do not have ON_ERROR_STOP set so why is this happening?
>>
>>
>
>How do you know ON_ERROR_STOP isn't set? Could it be set in
>a .psqlrc file? What does \set show?
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Michael, I didn't see the last comment in my previous replies. I know
that the variable isn't set because I embedded \set into the psql
commands so that they would output what is set.

Thanks,

Brad


Michael Fuhr wrote:

>On Fri, Jan 14, 2005 at 12:03:02PM +0000, Bradley Kieser wrote:
>
>
>
>>I have an admin script that drops a schema and then recreates it (quick
>>way to refresh from backup). However, if the schema doesn't exist, the
>>drop errors, as you would expect. The next SQL command, the schema
>>create, is never executed.
>>
>>
>
>How do you know the create is never executed? Are you looking for
>the schema and not finding it? How are you looking? Or is there
>an error message? What is it?
>
>Are you doing the drop and create in the same transaction? If so,
>then the drop statement's failure is preventing subsequent statements
>in that transaction from executing. If that's not the problem then
>please post a self-contained test case so we can see exactly what
>you're doing.
>
>
>
>>I do not have ON_ERROR_STOP set so why is this happening?
>>
>>
>
>How do you know ON_ERROR_STOP isn't set? Could it be set in
>a .psqlrc file? What does \set show?
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Okay, Michael gets that trophy! Thanks Michael, it needed a commit.
However, this is odd. I get a "No transaction in progress" error coming
out on the commit, but at least it works, so I am happy!

Thank you!

This works:
psql -U$dba $db << END
drop schema $repschema cascade;
commit;
create schema $repschema authorization $repuser;
END


Tis doesn't:

psql -U$dba $db << END
drop schema $repschema cascade;
create schema $repschema authorization $repuser;
END


Brad


Michael Fuhr wrote:

>On Fri, Jan 14, 2005 at 12:03:02PM +0000, Bradley Kieser wrote:
>
>
>
>>I have an admin script that drops a schema and then recreates it (quick
>>way to refresh from backup). However, if the schema doesn't exist, the
>>drop errors, as you would expect. The next SQL command, the schema
>>create, is never executed.
>>
>>
>
>How do you know the create is never executed? Are you looking for
>the schema and not finding it? How are you looking? Or is there
>an error message? What is it?
>
>Are you doing the drop and create in the same transaction? If so,
>then the drop statement's failure is preventing subsequent statements
>in that transaction from executing. If that's not the problem then
>please post a self-contained test case so we can see exactly what
>you're doing.
>
>
>
>>I do not have ON_ERROR_STOP set so why is this happening?
>>
>>
>
>How do you know ON_ERROR_STOP isn't set? Could it be set in
>a .psqlrc file? What does \set show?
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Fri, Jan 14, 2005 at 12:03:02PM +0000, Bradley Kieser wrote:

> I have an admin script that drops a schema and then recreates it (quick
> way to refresh from backup). However, if the schema doesn't exist, the
> drop errors, as you would expect. The next SQL command, the schema
> create, is never executed.

How do you know the create is never executed? Are you looking for
the schema and not finding it? How are you looking? Or is there
an error message? What is it?

Are you doing the drop and create in the same transaction? If so,
then the drop statement's failure is preventing subsequent statements
in that transaction from executing. If that's not the problem then
please post a self-contained test case so we can see exactly what
you're doing.

> I do not have ON_ERROR_STOP set so why is this happening?

How do you know ON_ERROR_STOP isn't set? Could it be set in
a .psqlrc file? What does \set show?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Fri, Jan 14, 2005 at 06:11:27PM +0000, Bradley Kieser wrote:

> Okay, Michael gets that trophy! Thanks Michael, it needed a commit.
> However, this is odd. I get a "No transaction in progress" error coming
> out on the commit, but at least it works, so I am happy!

What version of the client and server are you using? For the client
run "psql --version"; for the server execute "SELECT version();".
Where do you have autocommit set? PostgreSQL 7.4 removed autocommit
from the server and added it to the client; I wonder if you're using
differing client and server versions that are causing confusion.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

$ psql --version
psql (PostgreSQL) 7.4.1
contains support for command-line editing

# SELECT version();
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.2
(Mandrake Linux 10.0 3.3.2-6mdk)
(1 row)


Michael Fuhr wrote:

>On Fri, Jan 14, 2005 at 06:11:27PM +0000, Bradley Kieser wrote:
>
>
>
>>Okay, Michael gets that trophy! Thanks Michael, it needed a commit.
>>However, this is odd. I get a "No transaction in progress" error coming
>>out on the commit, but at least it works, so I am happy!
>>
>>
>
>What version of the client and server are you using? For the client
>run "psql --version"; for the server execute "SELECT version();".
>Where do you have autocommit set? PostgreSQL 7.4 removed autocommit
>from the server and added it to the client; I wonder if you're using
>differing client and server versions that are causing confusion.
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org