2011/5/13 Tom Lane :
> Grzegorz Szpetkowski writes:
>> I see that I just confused old PostgreSQL 8.3 curly bracket behaviour
>> with new 8.4/9.0 (I am using 8.3 all the time):
>
> Oh, you're right --- so I was mistaken to claim it had always been like
> that. Before we started using array_to_stri
Grzegorz Szpetkowski writes:
> I see that I just confused old PostgreSQL 8.3 curly bracket behaviour
> with new 8.4/9.0 (I am using 8.3 all the time):
Oh, you're right --- so I was mistaken to claim it had always been like
that. Before we started using array_to_string here, you *could* tell
the
I see that I just confused old PostgreSQL 8.3 curly bracket behaviour
with new 8.4/9.0 (I am using 8.3 all the time):
http://www.postgresql.org/docs/8.3/static/sql-grant.html
http://www.postgresql.org/docs/9.0/static/sql-grant.html
That's why I felt some misunderstanding with my previous post.
R
What about changing empty value in \dp (\z) to {} when priviliges are
really empty and leave column empty for default priviliges as it works
now. I mean the same behaviour as in relacl column in pg_class catalog
? It sound simplest for me:
empty string - default privileges
{} - no privileges
{post
Noah Misch writes:
>> Some initial debugging by RhodiumToad on #postgresql led to the following
>> observation: The error occurs only when the "SELECT ... WHERE i = a_bar();"
>> is being planned, not when it is being executed, with the snapshot being
>> used to plan the query apparently being t
"psql \dp showing empty Access privileges column for {}"
writes:
> Description:There is no difference between default and empty access
> privileges with \dp
Yeah. It's been like that since forever, and nobody's complained
before, possibly because revoking all privileges for everybody is
--On 12. Mai 2011 11:24:13 -0400 Tom Lane wrote:
This is on the
to-fix list --- in fact there was a patch submitted for it last year,
although it got returned for rework and we've not seen it again yet.
Yes, I didn't manage to provide a completed patch for 9.1...will try to
re-submit for 9
I wrote:
> Well, the main point here seems to be that you've got a function
> returning record, not just a scalar value which is what your initial
> example suggested. I've been able to duplicate the error and confirm
> that the behavior changed in 9.0, but have not yet tracked down why.
> More ne
On Wed, May 11, 2011 at 7:22 AM, Manoranjan Reddy wrote:
> #Stopping PostGreSQL, it didnt go through
> postgres{24} pg_ctl stop -D /usr/local/postgres/data/
> waiting for server to shut
> down.. . failed
> pg_ctl: server does not shut dow
On Fri, May 6, 2011 at 9:59 AM, alex wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6010
> Logged by: alex
> Email address: alexandr.kas...@gmail.com
> PostgreSQL version: 9.1 beta1
> Operating system: snow leopard
> Description: booting problem
I don't have the means to easily compile a PG build, but if there's a
place to get nightly builds or such I'd be happy to give it a shot and
report back.
On Wed, May 11, 2011 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Will commit 2e82d0b396473b595a30f68b37b8dfd41c37dff8 have possibly f
On Thursday 12 May 2011, you wrote:
> "Panos Christeas" writes:
> > CREATE TABLE test1(id SERIAL PRIMARY KEY,
> > name VARCHAR(20) NOT NULL);
> > CREATE TABLE test2(description TEXT) INHERITS(test1);
> > ALTER TABLE test2 ALTER name DROP NOT NULL;
> >
> > pg_dump that.
> > The dump will still
"Panos Christeas" writes:
> CREATE TABLE test1(
> id SERIAL PRIMARY KEY,
> name VARCHAR(20) NOT NULL
> );
> CREATE TABLE test2(
> description TEXT
> ) INHERITS(test1);
> ALTER TABLE test2 ALTER name DROP NOT NULL;
> pg_dump that.
> The dump will still have "not null" constr
On Thu, May 5, 2011 at 5:29 PM, Tom Lane wrote:
> Leon Widdershoven writes:
>> I have just installed Postgresql Beta 1 on a new Windows 7 64-bit system
>> (without a previously installed PostgreSQL).
>
>> When using pgAdmin III (included in the installer package) to create a
>> user (Login Role)
The following bug has been logged online:
Bug reference: 6024
Logged by: Panos Christeas
Email address: x...@linux.gr
PostgreSQL version: 9.0, 8.4
Operating system: Linux
Description:pg_dump won't dump ALTERed inherited fields
Details:
CREATE TABLE test1(
id SER
Hello Robert.
As I already wrote the reason was based on installation of ZendStudio 8.0
(30 day version for testing).
My LinuxMint was afterwards in an unexpected condition which comes to this
behaviour with postgreSQL.
Since I deinstalled ZendStudio, all the standard binaries of postgreSQL from
16 matches
Mail list logo
