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
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 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
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
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
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
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
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
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
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 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
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 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
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
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"
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
>
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
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
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
19 matches
Mail list logo
