On lör, 2011-12-10 at 16:16 +0100, Yeb Havinga wrote:
>
> * Cannot restrict access to array types. After revoking usage from the
> element type, the error is perhaps a bit misleading. (smallint[] vs
> smallint)
>
> postgres=> create table a (a int2[]);
> ERROR: permission denied for type small
Hello
2012/5/18 Miroslav Šimulčík :
> Hello.
>
> SQL 2011 standard wasn't available in time I started this project so I built
> my implementation on older standards TSQL2 and SQL/Temporal, that were only
> available. None of these were accepted by ANSI/ISO commissions however.
>
> There is differe
Peter Eisentraut writes:
> I found this in contrib/sepgsql/expected/label.out:
> SECURITY LABEL ON COLUMN t2
> IS 'system_u:object_r:sepgsql_ro_table_t:s0'; -- be failed
> ERROR: improper relation name (too many dotted names):
> Contrast with:
> SECURITY LABEL ON COLUMN t2.b
> IS 'sy
Peter Eisentraut writes:
> Currently, psql --version prints something like
> psql (PostgreSQL) 9.2beta1
> contains support for command-line editing
> I think the notice about readline is a leftover from the old days when
> psql was often built without any readline support. Nowadays, this looks
>
Excerpts from Florian Pflug's message of sáb may 19 03:48:51 -0400 2012:
>
> On May18, 2012, at 23:18 , Alvaro Herrera wrote:
> > Excerpts from Florian Pflug's message of jue may 17 09:08:26 -0400 2012:
> > Seems to me that we could make zero_damaged_pages an enum. The default
> > value of "on"
Jeff Janes writes:
> On Thu, May 17, 2012 at 11:35 AM, Joshua Berkus wrote:
>> That's in-RAM speed ... I ran the query twice to make sure the index was
>> cached, and it didn't get any better. And I meant 5X per byte rather than
>> 5X per tuple.
> Ah, OK that makes more sense. I played aroun
On Sun, May 20, 2012 at 01:24:21AM +0300, Peter Eisentraut wrote:
> Currently, psql --version prints something like
>
> psql (PostgreSQL) 9.2beta1
> contains support for command-line editing
I think this should be replaced with a notice about the actual library
used.
Cheers,
David.
--
David Fet
Hi,
I just read a very interesting post about "schema version management".
Quote: "You could set it up so that every developer gets their own
test database, sets up the schema there, takes a dump, and checks that
in. There are going to be problems with that, including that dumps
produced by pg_du
On Sun, May 20, 2012 at 3:24 PM, Tom Lane wrote:
> Another possibility is to try to reduce the costs of index_getnext_tid
> and FunctionCall2Coll, which are basically just trampolines to reach
> btgettuple. It's not immediately obvious how to make that much better
> though.
Hmm... this seems awf
On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson wrote:
> Hi,
>
> I just read a very interesting post about "schema version management".
>
> Quote: "You could set it up so that every developer gets their own
> test database, sets up the schema there, takes a dump, and checks that
> in. There are go
On Mon, May 21, 2012 at 8:08 AM, Daniel Farina wrote:
> I think you are absolutely right, but I'm not sure if teaching pg_dump
> a new option is the best idea. It's a pretty complex program as-is.
> I've also heard some people who really wish pg knew how to self-dump
> for valid reasons.
Complex
Excerpts from David Fetter's message of dom may 20 15:30:52 -0400 2012:
> On Sun, May 20, 2012 at 01:24:21AM +0300, Peter Eisentraut wrote:
> > Currently, psql --version prints something like
> >
> > psql (PostgreSQL) 9.2beta1
> > contains support for command-line editing
>
> I think this should
Alvaro Herrera writes:
> Excerpts from David Fetter's message of dom may 20 15:30:52 -0400 2012:
>> I think this should be replaced with a notice about the actual library
>> used.
> That was my thought as well, but is it possible to implement it?
And, more to the point, would it be more reliable
On Sun, May 20, 2012 at 7:36 PM, Joel Jacobson wrote:
> On Mon, May 21, 2012 at 8:08 AM, Daniel Farina wrote:
>> I think you are absolutely right, but I'm not sure if teaching pg_dump
>> a new option is the best idea. It's a pretty complex program as-is.
>> I've also heard some people who really
Excerpts from Tom Lane's message of dom may 20 23:04:59 -0400 2012:
>
> Alvaro Herrera writes:
> > Excerpts from David Fetter's message of dom may 20 15:30:52 -0400 2012:
> >> I think this should be replaced with a notice about the actual library
> >> used.
>
> > That was my thought as well, bu
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of dom may 20 23:04:59 -0400 2012:
>> And, more to the point, would it be more reliable than checking the
>> results of system-specific tools such as ldd?
> If well implemented, my guess is that it would be. For example recall
> that in D
On Mon, May 21, 2012 at 10:06 AM, Daniel Farina wrote:
> Also, now that I look more carefully, there was a lot of conversation
> about this patch; it seems like what you are doing now is reporting
> its successful use, and I did not understand that by reading the
> abstract of your email. And, be
On 20 May 2012 01:52, Daniel Farina wrote:
> The documentation is misleading to the point of our support for ISO
> 8601-strict parsing.
>
> http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php
>
> A very fine point, but I discovered it not out of curiosity, but a
> fairly angry user o
On Sun, May 20, 2012 at 10:34 PM, Brendan Jurd wrote:
> What we don't do is *output* the 'T', but this is pretty easy to
> workaround, e.g., to_char(now(), '-MM-DD"T"HH24:MI:SS'). The
> scope of actually wanting the 'T' is surely pretty minor?
>
> I'd be okay with just adding a note in the m
19 matches
Mail list logo
