2010/8/14 Itagaki Takahiro :
> 2010/8/10 Tom Lane :
>> Eventually it might be nice to have some sort of way to specify the
>> estimate to use for any aggregate function --- but for a near-term
>> fix maybe we should just hard-wire a special case for array_agg in
>> count_agg_clauses_walker().
>
> T
The following bug has been logged online:
Bug reference: 5620
Logged by: Samuel Marinov
Email address: samuel.mari...@gmail.com
PostgreSQL version: 9.0b4
Operating system: Ubuntu Linux 10.04 64-bit
Description:PostgreSQL won't accept the word "user" as a valid
column
2010/8/10 Tom Lane :
> Eventually it might be nice to have some sort of way to specify the
> estimate to use for any aggregate function --- but for a near-term
> fix maybe we should just hard-wire a special case for array_agg in
> count_agg_clauses_walker().
The attached patch is the near-term fix
writes:
> The sql statement 'ALTER TABLE DROP CONSTRAINT IF EXISTS
> ' returns with a syntax error on exists. The
> documentation states that the IF EXISTS clause is allowed in DROP
> CONSTRAINT statements.
Apparently you're reading 9.0 documentation and using a pre-9.0 server.
Please see the
The sql statement 'ALTER TABLE DROP CONSTRAINT IF EXISTS
' returns with a syntax error on exists. The
documentation states that the IF EXISTS clause is allowed in DROP
CONSTRAINT statements.
"mma...@janmedia.com" writes:
> 1. SQL queries where executed using JDBC.
> 2. I was trying to repeat the bug (executing 'direct queries', from psql)- I
> created a new table, added some rows, then alter table adding varchar column
> field (password_pdf) with DEFAULT NULL, added some rows problem
"Pierre" writes:
> Detailed operations:
> 1. on computer A, using PgAdmin3, backup of database x into file
> saveddb.backup
> 2. tranfer of this file to a directory of computer B, using NFS
> 3. on computer B, Restore of this file from the local directory won't work:
> 3.1. If it is the first att
More info on this issue:
1. SQL queries where executed using JDBC.
2. I was trying to repeat the bug (executing 'direct queries', from psql)- I
created a new table, added some rows, then alter table adding varchar column
field (password_pdf) with DEFAULT NULL, added some rows problem does not
occu
The following bug has been logged online:
Bug reference: 5619
Logged by: Pierre
Email address: pma...@neuf.fr
PostgreSQL version: 8.4.4
Operating system: Linux
Description:restore won't work with files transferred with NFS
Details:
Sorry, my previous report was sent
Heikki Linnakangas writes:
> On 13/08/10 18:18, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> PushOverrideSearchPath() assumes that if the temporary namespace existed
>>> when an override search path was memorized with GetOverrideSearchPath(),
>>> it must still exist. That's not true in the a
On 13/08/10 18:18, Tom Lane wrote:
Heikki Linnakangas writes:
PushOverrideSearchPath() assumes that if the temporary namespace existed
when an override search path was memorized with GetOverrideSearchPath(),
it must still exist. That's not true in the above example, rolling back
the transaction
Heikki Linnakangas writes:
> PushOverrideSearchPath() assumes that if the temporary namespace existed
> when an override search path was memorized with GetOverrideSearchPath(),
> it must still exist. That's not true in the above example, rolling back
> the transaction that the temporary namespa
On Fri, Aug 13, 2010 at 02:01:02PM +, Pierre wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5618
> Logged by: Pierre
> Email address: pma...@neuf.fr
> PostgreSQL version: 8.4.4
> Operating system: Linux
> Description:restore won't work wit
The following bug has been logged online:
Bug reference: 5618
Logged by: Pierre
Email address: pma...@neuf.fr
PostgreSQL version: 8.4.4
Operating system: Linux
Description:restore won't work with files transferred with NFS
Details:
Computer A running
Ubuntu 9.10,
O
Scott Wheeler wrote:
> Can you tell me what the pg_stat_tmp file is used for?
It's not a file; it's a subdirectory. The statistics information is
periodically written to a file within that subdirectory when
PostgreSQL is running.
I concur with prior advice -- make sure you don't have a post
"Leo Shklovskii" writes:
> If I put options after the filename to use for pg_restore.exe then it
> behaves in a very unintuitive way.
Hmm ... pg_dump is coded to complain about that, but pg_restore just
ignores any "extra" arguments after the filename. I agree that's not
too good, will fix.
The following bug has been logged online:
Bug reference: 5617
Logged by: Leo Shklovskii
Email address: l...@thermopylae.net
PostgreSQL version: 8.4.4
Operating system: Windows 7 (x86)
Description:pg_restore behaves unexpectedly on 'invalid' command
line
Details:
If
I already have done this but this file still remains. There is no problem with
windows, the compute is like new and runs everyting else smooth. This is the
only problem i have ever had, i have even tried deleting the file through CMD
but no luck it still will not delete. Can you tell me what th
hubert depesz lubaczewski writes:
> On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
>> I don't think this is a bug. The history file is read at psql startup
>> and written out (to the same file name) at exit. Those operations are
>> quite expensive, so it would be insane to do them aft
This leads to assertion failure, on versions 8.3 onwards where plan
cache invalidation was introduced:
postgres=# CREATE FUNCTION ttfunc() RETURNS VOID AS $$
begin
PERFORM * FROM temptable;
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
postgres=# begin;
BEGIN
postgres=# CREATE TEMPORARY TABLE temp
On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
> "David E. Wheeler" writes:
> > I have this in my .psqlrc:
> > \set HISTFILE ~/.psql_history- :DBNAME
> > This is great, except when I change databases in a session:
>
> > % psql foo
> > foo % \c bar
> > You are now connec
21 matches
Mail list logo
