Re: [HACKERS] [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1

2014-02-03 Thread Rajni Baliyan
Hi All,

Is there any way to automate the archive deletion process. Any script or
command in HA setup using pgpool

Thanks in advance

Best Regards,
*Rajni Baliyan | Database - Consultant*

*ASHNIK PTE. LTD.*101 Cecil Street, #11-11 Tong Eng Building, Singapore
069533
M : +65 83858518 T: +65 6438 3504 | www.ashnik.com
www.facebook.com/ashnikbiz | www.twitter.com/ashnikbiz

[image: email patch]

This email may contain confidential, privileged or copyright material and
is solely for the use of the intended recipient(s).


On Fri, Jan 31, 2014 at 11:22 AM, Bruce Momjian br...@momjian.us wrote:

 On Fri, Jul 26, 2013 at 06:28:05PM -0400, Tom Lane wrote:
  Our documentation appears not to disclose this fine point, but a look
  at the SQL-MED standard says it's operating per spec.  The standard also
  says that ADD is an error if the option is already defined, which is a
  bit more defensible, but still not exactly what I'd call user-friendly.
  And the error we issue for that case is pretty misleading too:
 
  regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true')
 ;
  ALTER SERVER
  regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate
 'false') ;
  ERROR:  option use_remote_estimate provided more than once
 
  I think we could do with both more documentation, and better error
  messages for these cases.  In the SET-where-you-should-use-ADD case,
  perhaps
 
  ERROR:  option use_remote_estimate has not been set
  HINT: Use ADD not SET to define an option that wasn't already set.
 
  In the ADD-where-you-should-use-SET case, perhaps
 
  ERROR:  option use_remote_estimate is already set
  HINT: Use SET not ADD to change an option's value.
 
  The provided more than once wording would be appropriate if the same
  option is specified more than once in the command text, but I'm not sure
  that it's worth the trouble to detect that case.

 Where are on this?

 --
   Bruce Momjian  br...@momjian.ushttp://momjian.us
   EnterpriseDB http://enterprisedb.com

   + Everyone has their own god. +


 --
 Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-general

image002.jpg

Re: [HACKERS] [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1

2013-08-02 Thread BladeOfLight16
On Fri, Jul 26, 2013 at 6:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 snip

 I think we could do with both more documentation, and better error
 messages for these cases.  In the SET-where-you-should-use-ADD case,
 perhaps

 ERROR:  option use_remote_estimate has not been set
 HINT: Use ADD not SET to define an option that wasn't already set.

 In the ADD-where-you-should-use-SET case, perhaps

 ERROR:  option use_remote_estimate is already set
 HINT: Use SET not ADD to change an option's value.

 snip

 Thoughts, better wordings?


Since SET is more or less a keyword in this context and there's already not
some obvious things about it, it might be better to avoid using it with a
slightly different meaning in the error messages. Maybe defined would be
clearer? That would be consistent with your usage of define in the first
error message as well.

ERROR:  option use_remote_estimate has not been defined
HINT: Use ADD not SET to define an option that wasn't already defined.

ERROR:  option use_remote_estimate is already defined
HINT: Use SET not ADD to change an option's value.

Just a thought.


Re: [HACKERS] [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1

2013-07-26 Thread Tom Lane
Lonni J Friedman netll...@gmail.com writes:
 nightly=# ALTER SERVER cuda_db10 OPTIONS (SET use_remote_estimate 'true') ;
 ERROR:  option use_remote_estimate not found

 Am I doing something wrong, or is this a bug?

[ experiments... ]  You need to say ADD, not SET, to add a new option to
the list.  SET might more appropriately be spelled REPLACE, because it
requires that the object already have a defined value for the option,
which will be replaced.

Our documentation appears not to disclose this fine point, but a look
at the SQL-MED standard says it's operating per spec.  The standard also
says that ADD is an error if the option is already defined, which is a
bit more defensible, but still not exactly what I'd call user-friendly.
And the error we issue for that case is pretty misleading too:

regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true') ;
ALTER SERVER
regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'false') ;
ERROR:  option use_remote_estimate provided more than once

I think we could do with both more documentation, and better error
messages for these cases.  In the SET-where-you-should-use-ADD case,
perhaps

ERROR:  option use_remote_estimate has not been set
HINT: Use ADD not SET to define an option that wasn't already set.

In the ADD-where-you-should-use-SET case, perhaps

ERROR:  option use_remote_estimate is already set
HINT: Use SET not ADD to change an option's value.

The provided more than once wording would be appropriate if the same
option is specified more than once in the command text, but I'm not sure
that it's worth the trouble to detect that case.

Thoughts, better wordings?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1

2013-07-26 Thread Lonni J Friedman
On Fri, Jul 26, 2013 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Lonni J Friedman netll...@gmail.com writes:
 nightly=# ALTER SERVER cuda_db10 OPTIONS (SET use_remote_estimate 'true') ;
 ERROR:  option use_remote_estimate not found

 Am I doing something wrong, or is this a bug?

 [ experiments... ]  You need to say ADD, not SET, to add a new option to
 the list.  SET might more appropriately be spelled REPLACE, because it
 requires that the object already have a defined value for the option,
 which will be replaced.

 Our documentation appears not to disclose this fine point, but a look
 at the SQL-MED standard says it's operating per spec.  The standard also
 says that ADD is an error if the option is already defined, which is a
 bit more defensible, but still not exactly what I'd call user-friendly.
 And the error we issue for that case is pretty misleading too:

 regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true') ;
 ALTER SERVER
 regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'false') ;
 ERROR:  option use_remote_estimate provided more than once

 I think we could do with both more documentation, and better error
 messages for these cases.  In the SET-where-you-should-use-ADD case,
 perhaps

 ERROR:  option use_remote_estimate has not been set
 HINT: Use ADD not SET to define an option that wasn't already set.

 In the ADD-where-you-should-use-SET case, perhaps

 ERROR:  option use_remote_estimate is already set
 HINT: Use SET not ADD to change an option's value.

 The provided more than once wording would be appropriate if the same
 option is specified more than once in the command text, but I'm not sure
 that it's worth the trouble to detect that case.

 Thoughts, better wordings?

Thanks Tom, I've confirmed that using ADD was the solution.  I think
your suggested updated ERROR  HINT text is an excellent improvement.
It definitely would have given me the clue I was missing earlier.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers