On Tuesday, February 28, 2012 11:44:09 am James B. Byrne wrote:
>
> I encountered a strange inconsistency with PGAdmin3-1.14.2
> relating to this. After executing "ALTER LANGUAGE plpgsql
> owner to devl;" in the SQL query pane inside PGAdmin3 the
> extension ownership change is never reflected i
On Tue, February 28, 2012 14:17, Adrian Klaver wrote:
> No, you just did not run into the issue, probably
> because your template1 was just a straight clone of
> template0 with no added features
>
You are correct. It was the inability to change the
comment on the extension as required by the pg
On Tue, February 28, 2012 14:03, Adrian Klaver wrote:
>>
>
> The PgAdmin folks would be better able to help you with
> the exact reason
> for the above, but I suspect they really meant:
>
> http://www.postgresql.org/docs/9.1/interactive/sql-alterlanguage.html
>
> ALTER [ PROCEDURAL ] LANGUAGE nam
On 02/28/2012 10:52 AM, James B. Byrne wrote:
This behaviour effectively means that only the superuser
can restore databases in 9.1 or build them from scripts;
unless the default template is altered. Is this desired?
What then does GRANT CREATE DATABASE mean in 9.1 then? It
is certainly at od
On 02/28/2012 10:52 AM, James B. Byrne wrote:
On Tue, February 28, 2012 13:28, Adrian Klaver wrote:
Why does this not work?
=> \c test
You are now connected to database "test" as user "devl".
ALTER EXTENSION plpgsql OWNER TO devl;
ERROR: syntax error at or near "OWNER"
LINE 1: ALTER EXTEN
On 02/28/2012 10:37 AM, James B. Byrne wrote:
On Tue, February 28, 2012 12:52, Adrian Klaver wrote:
On 02/28/2012 09:50 AM, James B. Byrne wrote:
Sigh. I will have to think on this before changing
anything.
To my mind, the most straight-forward way of dealing
with
this is to remove the lan
On Tue, February 28, 2012 13:28, Adrian Klaver wrote:
>>
>> Why does this not work?
>>
>> => \c test
>> You are now connected to database "test" as user "devl".
>> ALTER EXTENSION plpgsql OWNER TO devl;
>> ERROR: syntax error at or near "OWNER"
>> LINE 1: ALTER EXTENSION plpgsql OWNER TO devl;
On Tue, February 28, 2012 12:52, Adrian Klaver wrote:
> On 02/28/2012 09:50 AM, James B. Byrne wrote:
>>
>>
>> Sigh. I will have to think on this before changing
>> anything.
>>
>> To my mind, the most straight-forward way of dealing
>> with
>> this is to remove the language from template1
>> alt
On 02/28/2012 10:23 AM, James B. Byrne wrote:
On Tue, February 28, 2012 12:17, Adrian Klaver wrote:
I guess the options are either do as I did above or
create a new template database as the owner you want
and use that as the template for your CREATE
DATABASE.
Why does this not work?
=> \
On Tue, February 28, 2012 12:17, Adrian Klaver wrote:
>
> I guess the options are either do as I did above or
> create a new template database as the owner you want
> and use that as the template for your CREATE
> DATABASE.
Why does this not work?
=> \c test
You are now connected to database "
On 02/28/2012 09:50 AM, James B. Byrne wrote:
Sigh. I will have to think on this before changing anything.
To my mind, the most straight-forward way of dealing with
this is to remove the language from template1 altogether.
Thereafter, the db owner must explicitly add it back in
where required
On Tue, February 28, 2012 12:17, Adrian Klaver wrote:
> Alright here is what I found:
>
> template1=# \dL
> List of languages
> Name | Owner | Trusted
> -+--+-
> plpgsql | postgres | t
>
> template1=# CREATE DATABASE pl_test with owner=aklaver;
> CREATE DATABA
On Mon, Feb 27, 2012 at 6:22 PM, James B. Byrne wrote:
>
> On Mon, February 27, 2012 17:16, Adrian Klaver wrote:
> >
> >
> > From psql do \l and see who actually owns the database.
> >
>List of databases
> Name|Owner | Encod
On Mon, February 27, 2012 17:16, Adrian Klaver wrote:
>
>
> From psql do \l and see who actually owns the database.
>
List of databases
Name|Owner | Encoding |
---+--+--+--
devl
On Monday, February 27, 2012 1:45:13 pm James B. Byrne wrote:
> On Mon, February 27, 2012 16:37, Adrian Klaver wrote:
> It is likely that I created the database initially in
> PGAdmin3 while connected to the server as the postgres
> user. Why would creating a database with a specified
> owner res
On Mon, February 27, 2012 16:37, Adrian Klaver wrote:
> On Monday, February 27, 2012 1:23:22 pm James B. Byrne
> wrote:
>> Obviously, I am missing something important here. The
>> database in question is created thusly:
>>
>> CREATE DATABASE test
>> WITH OWNER = devl
>>ENCODING = 'UTF8'
On Monday, February 27, 2012 1:23:22 pm James B. Byrne wrote:
> Obviously, I am missing something important here. The
> database in question is created thusly:
>
> CREATE DATABASE test
> WITH OWNER = devl
>ENCODING = 'UTF8'
>TABLESPACE = pg_default
>LC_COLLATE = 'en_US.UT
Obviously, I am missing something important here. The
database in question is created thusly:
CREATE DATABASE test
WITH OWNER = devl
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
CONNECTION LIMIT = -1;
The manua
Here is an interesting situation. In PGAdmin3-1.14.2 when
I display the extension properties then I see this:
CREATE EXTENSION plpgsql
SCHEMA pg_catalog
VERSION "1.0";
ALTER EXTENSION plpgsql
OWNER TO postgres;
However, if I do this exact statement in the SQL pane
while connected as the
On Mon, February 27, 2012 15:44, Tom Lane wrote:
> "James B. Byrne" writes:
>> 1. Can the comments be suppressed?
>
> No.
>
>> 2. Why is this an error in the first place?
>
> Because you're not running the script as superuser.
>
> regards, tom lane
>
Why is it necessary to
On Monday, February 27, 2012 11:44:09 am James B. Byrne wrote:
>
> 3. Why are these dependencies not owned by the database
> owner to begin with? Surely this code:
>
> CREATE EXTENSION plpgsql
> SCHEMA pg_catalog
> VERSION "1.0";
> ALTER EXTENSION plpgsql
> OWNER TO postgres;
>
> could
"James B. Byrne" writes:
> 1. Can the comments be suppressed?
No.
> 2. Why is this an error in the first place?
Because you're not running the script as superuser.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On Mon, February 27, 2012 14:30, Adrian Klaver wrote:
> On 02/27/2012 08:51 AM, James B. Byrne wrote:
>
>>
>> The options seem to be run the script as the owner of
>> the
>> plpgsql EXTENSION or do not include the comment.
>>
>> How does one instruct pg_dump not to include the COMMENT
>> for the p
On Mon, February 27, 2012 13:54, Adrian Klaver wrote:
> On 02/27/2012 08:51 AM, James B. Byrne wrote:
>>
>> The options seem to be run the script as the owner of
>> the
>> plpgsql EXTENSION or do not include the comment.
>>
>> How does one instruct pg_dump not to include the COMMENT
>> for the plp
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
Did some testing. So when you use 9.1 pg_dump to dump f
On 2/27/12 9:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
The case in question is the automated creation of an sql
sc
On 02/27/2012 08:51 AM, James B. Byrne wrote:
The options seem to be run the script as the owner of the
plpgsql EXTENSION or do not include the comment.
How does one instruct pg_dump not to include the COMMENT
for the plpgsql extension?
I am not sure pg_dump is including the COMMENT. From you
On: Fri, 24 Feb 2012 07:33:01 -0800, Adrian Klaver
wrote:
> On Friday, February 24, 2012 7:16:47 am James B. Byrne
> wrote:
>> CentOS-5.7
>> RoR-3.1.1
>> Pg-9.1
>>
>> I am trying to run a test suite against Pg-9.1 for a
>> RoR-3.1.1 based application. When I run the test DB
>> setup task it fails
28 matches
Mail list logo
