Re: [BUGS] BUG #5032: unexpected syntax error for plpgsql function returns table
2009/9/3 Keith Cascio : > Pavel, > > On Thu, 3 Sep 2009, Pavel Stehule wrote: > >> it's not bug - PostgreSQL doesn't support parameter placeholder on this >> position. Use dynamic query instead - plpgsql statement EXECUTE. > > Thank you for your reply. I appreciate your suggestion, but it still seems > like > a bug to me. Please comment on the fact that the following code succeeds: > > create function reproduce() returns table(foo integer) language plpgsql as > 'begin return query select 1 bar; end;'; > > Output in psql is: > CREATE FUNCTION > > Why should it succeed with "bar" but not with "foo"? because bar isn't declared as variable regards Pavel > > Thanks, > Keith > > >> 2009/9/3 Keith Cascio : >> > create function reproduce() returns table(foo integer) language plpgsql as >> > 'begin return query select 1 foo; end;'; > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [NOVICE] [BUGS] psql: FATAL: the database system is in recovery mode
On Tue, 2009-09-01 at 12:17 +0530, Bhushan Verma wrote: > > But my fedora 9 machine have as follows postgres version. > rpm -qa|grep postgres > postgresql-server-8.3.1-1.fc9.i386 Please note that you will need to follow this procedure before updating PostgreSQL on Fedora 9: https://fedoraproject.org/wiki/Enabling_new_signing_key#Fedora_9 Otherwise it will stay on 8.3.1 . -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #5032: unexpected syntax error for plpgsql function returns table
Pavel, On Thu, 3 Sep 2009, Pavel Stehule wrote: > 2009/9/3 Keith Cascio : > > Why should it succeed with "bar" but not with "foo"? > > because bar isn't declared as variable I understand now. returns table(v1 t1, v2 t2,...) is equivalent to declaring OUT parameters, therefore "foo" is an out parameter. Thank you for your patience sir. Keith -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5032: unexpected syntax error for plpgsql function returns table
On Sep 2, 2009, at 11:27 PM, Pavel Stehule wrote: Hello it's not bug - PostgreSQL doesn't support parameter placeholder on this position. Use dynamic query instead - plpgsql statement EXECUTE. It may not be a bug exactly, but it sure isn't a feature. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5032: unexpected syntax error for plpgsql function returns table
2009/9/3 Robert Haas : > On Sep 2, 2009, at 11:27 PM, Pavel Stehule wrote: > >> Hello >> >> it's not bug - PostgreSQL doesn't support parameter placeholder on >> this position. Use dynamic query instead - plpgsql statement EXECUTE. > > It may not be a bug exactly, but it sure isn't a feature. I hope so this problem will be solved at 8.5 pavel > > ...Robert > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5032: unexpected syntax error for plpgsql function returns table
On Thu, Sep 3, 2009 at 12:48 AM, Keith Cascio wrote: > Pavel, > > On Thu, 3 Sep 2009, Pavel Stehule wrote: > >> it's not bug - PostgreSQL doesn't support parameter placeholder on this >> position. Use dynamic query instead - plpgsql statement EXECUTE. > > Thank you for your reply. I appreciate your suggestion, but it still seems > like > a bug to me. Please comment on the fact that the following code succeeds: > > create function reproduce() returns table(foo integer) language plpgsql as > 'begin return query select 1 bar; end;'; > > Output in psql is: > CREATE FUNCTION > > Why should it succeed with "bar" but not with "foo"? This is a very common gotcha in plpgsql. I always prefix function arguments and and locals with _; merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] lost statistics; analyze needs to execute twice
Tom Lane wrote: > 4. At completion of ANALYZE, the regular tabstat machinery sends > off a tabstat message for the table, because guess what, ANALYZE did a > scan of that table, and there are t_blocks_fetched counts to report. > > 5. pgstat_recv_tabstat happily creates a table entry. (The pg_statio > counts in it are nonzero, even though the pg_stat counts aren't.) > > 6. Now, if you repeat the cycle, the stats collector will accept > the second PgStat_MsgAnalyze message, because this time there's > a stats table entry. > > This is a bit silly I guess --- we dropped the data but didn't actually > save any stats-table space. > > I'm inclined to think that the don't-create-a-table-entry behavior in > pgstat_recv_vacuum and pgstat_recv_analyze should just be dropped. > I'm dubious that it ever worked as intended. To have it work right > you'd need to suppress vacuum/analyze physical I/O from the tabstats > counts, which doesn't seem like an amazingly good idea. Moreover, > autovacuum is unlikely to issue vacuum or analyze against a table > that hasn't already got a stats-table entry, so the filter doesn't > seem likely to buy much if it did work. There might have been some > value in the idea back when cron-driven database-wide VACUUM ANALYZE > was the standard maintenance mechanism, but that's not the recommended > thing anymore. I think this business about supressing pgstat entries started because of autovacuum. I wasn't too fond of the idea at the time. I wouldn't be opposed to ripping it out either. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5031: DATE_TRUNC returns the wrong value when specifying MONTH
You're correct. When I run this from psql it returns the correct result. When I
run it from DBVisualizer, which I normally use, it adjust the result to my
local time zone. Thanks for looking into it. Sorry about bugging you with that.
Thanks,
Mark
On 9/2/09 10:24 PM, "Tom Lane" wrote:
Mark Douglas writes:
> I have my timezone set to GMT so there really shouldn't be any time zone
> adjustments.
Okay ...
postgres=# set timezone = GMT;
SET
postgres=# SELECT DATE_TRUNC('MONTH', CURRENT_DATE);
date_trunc
2009-09-01 00:00:00+00
(1 row)
I suspect there's something you're not telling us, like you're
using a client-side library that is doing timezone adjustments
behind your back.
regards, tom lane
[BUGS] BUG #5033: Fallback using Warm Standby
The following bug has been logged online: Bug reference: 5033 Logged by: Raja Rayaprol Email address: raja.rayap...@swift.com PostgreSQL version: 8.4 Operating system: HP-UX Description:Fallback using Warm Standby Details: I am applying archive logs at a warm standby and then brought up the standby. However if I want to set up the old primary as a standby, I am required to clone the standby to the primary. It is not practical to do such cloning across a WAN for a large database, and Oracle allows you to switch roles without requiring the standby to be recreated. I would like to know if there is demand for similar functionality from Postgres users, and whether PostgreSQL Plus (or other variant) offer any relief in this area ? Thanks and regards -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5034: plperlu problem with gethostbyname
The following bug has been logged online: Bug reference: 5034 Logged by: Diego de Lima Email address: diego_de_l...@hotmail.com PostgreSQL version: 8.3.7 Operating system: Linux Fedora 10 Description:plperlu problem with gethostbyname Details: The gethostbyname Perl internal function doesn't work properly on 8.3.7, returning "1" instead of the desired data array. On Postgres 8.2.x it works perfectly. Using Perl v5.10.0. Using Fedora 10 default rpm packages, all updated last month via yum. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5033: Fallback using Warm Standby
On tor, 2009-09-03 at 20:53 +, Raja Rayaprol wrote: > I would like to know if there is demand for similar functionality from > Postgres users, and whether PostgreSQL Plus (or other variant) offer > any > relief in this area ? This doesn't appear to be a bug. You might get better feedback from a different mailing list. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
