decibel writes:
> The gripe I have with \d is that the "footnotes" are very hard to
> scan through once you have more than a few things on a table. What
> I'd like to see is a version that provides the same information, but
> in a tabular output.
Hmm, I'm not visualizing what you have in mi
On May 8, 2009, at 3:43 PM, Alvaro Herrera wrote:
Well, you can see that with \d on the table, but IMHO this should be
present on \di too, so +1.
One gripe I had with \d and indexes the other day is that it sucks on
functional indexes -- it just says "pg_expression_1".
The gripe I have with \
Robert Haas writes:
> On Mon, May 18, 2009 at 4:03 PM, Stefan Keller wrote:
>> I'd expect functions like get_text() or get_url() in order to do the
>> following:
>> INSERT INTO collection(id, path, content) VALUES(1, '/tmp/mytext,
>> get_text('/tmp/mytext));
Apparently you've not found pg_read_f
On Mon, May 18, 2009 at 4:03 PM, Stefan Keller wrote:
> How to insert a text file into a field in PostgreSQL?
> I'd like to insert a row with fields from a local or remote text file.
> I'd expect functions like get_text() or get_url() in order to do the
> following:
> INSERT INTO collection(id, pa
How to insert a text file into a field in PostgreSQL?
I'd like to insert a row with fields from a local or remote text file.
I'd expect functions like get_text() or get_url() in order to do the
following:
INSERT INTO collection(id, path, content) VALUES(1, '/tmp/mytext,
get_text('/tmp/mytext));
AFA
On Mon, May 18, 2009 at 11:46 AM, Sebastien FLAESCH wrote:
> Hello,
>
> I try to use the new 8.4 INTERVAL type with libpq, but get crazy with
> the input formatting rules...
[this question is more appropriate on -general]
> I use PQprepare() / PQexecPrepared() with parameter list, binding the
>
Hello,
I try to use the new 8.4 INTERVAL type with libpq, but get crazy with
the input formatting rules...
I use PQprepare() / PQexecPrepared() with parameter list, binding the
INTERVAL values with the 1186 pg_type (is this ok?) and passing a
string buffer with values like:
"12345" for an INT
Hi,
I encountered the following compiler warning in 8.4dev.
Attached is the patch to fix this problem. Is this worth committing?
--
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:606: warning: format not a string literal and no format arguments
--
$
Martijn van Oosterhout writes:
> On Tue, May 12, 2009 at 05:55:13PM -0400, Tom Lane wrote:
>> I've about come to the conclusion that the only real fix is to abandon
>> our attempt to manage libxml's memory usage.
> Perhaps we could suggest to the libxml authors that it would be nice of
> the allo
On Tue, May 12, 2009 at 05:55:13PM -0400, Tom Lane wrote:
> I've been poking at the problems described here:
> http://archives.postgresql.org/message-id/20090306191404.gk3...@alvh.no-ip.org
> http://archives.postgresql.org/message-id/5265.1240417...@sss.pgh.pa.us
>
> I've about come to the conclus
I found following problem:
postgres=# create or replace function sum_items(anyarray) returns
anyelement as $$ select sum($1[i]) from
generate_series(array_lower($1,1), array_upper($1,1)) g(i)$$ language
sql immutable;
CREATE FUNCTION
Time: 1,983 ms
postgres=# select sum_items(array[1,2,3]);
ERROR:
Hi,
Since pg_restore --clean doesn't delete existing large objects,
restoring to an existing database with "pg_restore --clean -1"
would fail if backup archive contains large objects. Some DBAs
complain to the behavior because they expect all existing data
conflicting with backup archive will be d
12 matches
Mail list logo
