Re: [BUGS] BUG #7685: last_value() not consistent throughout window partition

2012-11-23 Thread Wes Devauld
Sorry for wasting your time, I now see: If frame_end is omitted it defaults to CURRENT ROW. clearly in the documentation. I made the assumption that the default was UNBOUNDED PROCEDING/FOLLOWING which is now very obviously not the case. Again, sorry for not really taking the time to ensure this

[BUGS] BUG #7686: Provider not configured.

2012-11-23 Thread bontha . manojrao
The following bug has been logged on the website: Bug reference: 7686 Logged by: Manoj Email address: bontha.manoj...@tcs.com PostgreSQL version: 9.2.1 Operating system: Windows Description: Dear Team, I have installed PostgreSQL in my system and trying to connect t

Re: [BUGS] BUG #6722: Debugger broken?

2012-11-23 Thread Astolfo
Hi Could someone provide a short howto about installing debugger for PostgreSQL 9.1 and 9.2? Even a couple of lines would be very helpful. I did not find pldbgapi.sql in the share/contrib folder and the instructions that one finds online appear outdated. Thanks in advance. A. -- View this m

Re: [BUGS] BUG #6722: Debugger broken?

2012-11-23 Thread Astolfo
Here is the two-lines howto for PG 9.2 for Windows. Uncomment and edit postgresql.conf: shared_preload_libraries = '$libdir/plugin_debugger' NB: in 9.2 the plugin_debugger.dll is not in the (non-existing) $libdi/plugins folder. Restart the server. Run CREATE EXTENSION pldbgapi; Cheers, A.

[BUGS] w7 vs linux

2012-11-23 Thread Peter Kroon
Is pgsql faster on linux? Currently I've made an installation on W7 and the converted queries are about 3 times slower then on mssql. There's still some optimization to do tho...but the current results don't look to good.

Re: [BUGS] w7 vs linux

2012-11-23 Thread Peter Kroon
Ignore, wrong list... My apologies.. Best, Peter 2012/11/23 Peter Kroon > Is pgsql faster on linux? > Currently I've made an installation on W7 and the converted queries are > about 3 times slower then on mssql. > There's still some optimization to do tho...but the current results don't > look

Re: [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Euler Taveira
On 22-11-2012 04:27, Pavel Stehule wrote: > 2012/11/21 Greg Sabino Mullane : Separately, what are > the objections to raising the size limit to 128? > >> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. -- Euler Taveira de Oliveira - Timbira h

Re: [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Pavel Stehule
2012/11/23 Euler Taveira : > On 22-11-2012 04:27, Pavel Stehule wrote: >> 2012/11/21 Greg Sabino Mullane : Separately, what are >> the objections to raising the size limit to 128? >> >>> significantly larger catalog >> > Less than 5% of catalog columns? I don't buy your argument. default 6201kB (6

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Tom Lane
Euler Taveira writes: > On 22-11-2012 04:27, Pavel Stehule wrote: >>> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Heikki Linnakangas
On 23.11.2012 17:53, Tom Lane wrote: Euler Taveira writes: On 22-11-2012 04:27, Pavel Stehule wrote: significantly larger catalog Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Tom Lane
Heikki Linnakangas writes: > On 23.11.2012 17:53, Tom Lane wrote: >> We could avoid this problem if we were prepared to make type "name" >> be varlena, ... > It would actually be nice to do that because it would *reduce* the > amount of space and memory used for the catalogs in the typical case

Re: [BUGS] BUG #7683: pg_upgrade missing configuration file

2012-11-23 Thread Bruce Momjian
On Tue, Nov 20, 2012 at 11:23:13AM +, bernhard.schra...@innogames.de wrote: > To point this out, postgresql 9.0 and 9.2 are not running, if 9.0 is > running, the 9.0 tests succeed, but afaik they shouldn't running, or at > least 9.2 shouldn't running during upgrade, but without the link to the