Re: [DOCS] Please provide stable target anchors

2010-08-09 Thread Robert Haas 
On Sun, Aug 8, 2010 at 2:38 PM, Daniele Varrazzo
 wrote:
> On Fri, Aug 6, 2010 at 7:01 PM, Robert Haas  wrote:
>> On Wed, Aug 4, 2010 at 3:03 PM, Daniele Varrazzo
>>  wrote:
>
>>> Patches are available from the git clone at
>>> . I've prepared patches for 8.4
>>> and 9.0 (branches "fixanchor-8-4" and "fixanchor-9-0").
>>
>> Could you post a diff?
>
> Attached

Thanks, this looks nice.  And useful.  Committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] ECPG - Some errno definitions don't match to the manual

2010-08-09 Thread Robert Haas 
2010/7/22 Satoshi Nagayasu :
> Hi all,
>
> I'm looking into some ecpg part of the official manual,
> and I have found some strange things.
>
> I'm now investigating SQLCODE and SQLSTATE, and I have found
> that some of the errno definitions don't match to the manual.
>
> For example, the manual says that ECPG_CONVERT_BOOL could be `-207'.
> However, ECPG_CONVERT_BOOL is defined as `-211' in ecpgerrno.h.
>
>> -207 (ECPG_CONVERT_BOOL)
>>
>>     This means the host variable is of type bool and the datum in the 
>> database is neither 't' nor 'f'. (SQLSTATE 42804)
>
> http://www.postgresql.org/docs/9.0/static/ecpg-errors.html
>
>> #define ECPG_NUMERIC_FORMAT           -207
>> #define ECPG_CONVERT_BOOL             -211
>
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/include/ecpgerrno.h?rev=1.27;content-type=text%2Fx-cvsweb-markup;only_with_tag=REL9_0_STABLE
>
> What does it mean? The manual is not up to date?

Yeah, I think that's what it means.  Perhaps you could provide a patch
for the docs?

Another question is whether we oughn't to remove all mention of the
specific values of these constants from the documentation.  That
wouldn't prevent all problems in this area, because constants can
still be added and removed, but ISTM that including the specific
numerical values here is encouraging people to depend on those values
when they probably shouldn't.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] pgbench acronym tps

2010-08-09 Thread Robert Haas 
On Fri, Aug 6, 2010 at 7:43 PM, Erik Rijkers  wrote:
> I noticed that pgbench.sgml (or the manual elsewhere)
> does not explicitly mention what TPS stands for;
> I thought it might be useful to add.
>
> (reason I checked: someone on #postgresql took tps
> to mean 'tuples per second')

The previous paragraph already mentions this, doesn't it?

Although perhaps instead of saying "The last two lines report the
rate..." we could say "The last two lines report the number of
transactions per second...".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] ECPG - Some errno definitions don't match to the manual

2010-08-09 Thread Satoshi Nagayasu 

On 2010/08/09 21:27, Robert Haas wrote:

I'm now investigating SQLCODE and SQLSTATE, and I have found
that some of the errno definitions don't match to the manual.



What does it mean? The manual is not up to date?


Yeah, I think that's what it means.  Perhaps you could provide a patch
for the docs?


Sure, I will make a patch for this. Please wait a moment.


Another question is whether we oughn't to remove all mention of the
specific values of these constants from the documentation.  That
wouldn't prevent all problems in this area, because constants can
still be added and removed, but ISTM that including the specific
numerical values here is encouraging people to depend on those values
when they probably shouldn't.


Hmm, it's a difficult point. From the application programmers' viewpoint, error 
codes and error numbers would be an interface between their application and 
PostgreSQL internals. So I think (and I hope) it should be in the programmer's 
manual. On the other hand, from the PostgreSQL developer's viewpoint, it is 
hard to maintain all of documents up to date. So removing them from the manual 
will make maintenance easier.

I found that this difference was generated by the very very old change in the code 
repository. And I think it would never be happen anymore, because nowadays PostgreSQL 
developers, especially code reviewers, always require "document 
updates/patches" for any patches before applying. (as all you know :)

I agree with that taking care about both code and documents is not so easy, but 
the current review/development process seems to be appropriate.

Any comments or suggestions?

--
NAGAYASU Satoshi 

--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Documentation improvement for PQgetResult

2010-08-09 Thread Marko Kreen 
On 8/6/10, Tom Lane  wrote:
> Daniele Varrazzo  writes:
>  > documentation about the PQgetResult function suggests to "[call]
>  > repeatedly until it returns a null pointer, indicating that the
>  > command is done". This has lead psycopg developers to write code with
>  > the pattern:
>
>  > while (NULL != (res = PQgetResult(conn))) {
>  > /* do something with res */
>  > PQclear(res);
>  > }
>
>  > Marko Kreen has pointed out
>  > (http://lists.initd.org/pipermail/psycopg/2010-July/007149.html) that
>  > this can lead to an infinite loop if the connection goes bad at the
>  > rightly wrong time, advising then to check for the connection status
>  > in the middle of the loop. libpq code seems actually returning
>  > PQmakeEmptyPGresult(conn, PGRES_FATAL_ERROR) in case of something
>  > unexpected.
>
>  > If this is the case (I've not managed to reproduce it but the libpq
>  > code seems clear), shouldn't the function documentation warn for this
>  > risk, advising to check the connection status in the middle of the
>  > loop and bail out if it's bad?
>
>
> No.
>
>  I'm not convinced we need to do anything about that, since AFAIR no one
>  has ever reported such a failure from the field (which might well
>  indicate that Marko's analysis is wrong, anyway).  But if we were to do
>  something about it, changing the documentation would be the wrong
>  response, because that coding pattern is all over the place.  It'd be
>  better to kluge PQgetResult so it only returns a bad-connection error
>  object once per query, or something like that.

So the PQgetResult currently does not guarantee that, yes?
As that's what I noticed...

Few facts that I have:
- psycopg2 was in such loop.
- libpq [8.4.2] issued close(-1) per PQgetResult call.
  Due to accident, it was without debug symbols, so I could not
  analyze deeply.
- There were 2 processes in such state.
- NIC problem - corrupted the stream after multi-GB data transfer,
  but not always.  In this case, there were large COPY-ing
  going on.
- There were 5 dbs in the machine that were copying data.  Some
  of them failed with data-format error, some perhaps succeeded.
- The NIC has been changed, so its probably not reproducible easily.

-- 
marko

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] ECPG - Some errno definitions don't match to the manual

2010-08-09 Thread Satoshi Nagayasu 

On 2010/08/10 1:36, Satoshi Nagayasu wrote:

On 2010/08/09 21:27, Robert Haas wrote:

I'm now investigating SQLCODE and SQLSTATE, and I have found
that some of the errno definitions don't match to the manual.



What does it mean? The manual is not up to date?


Yeah, I think that's what it means. Perhaps you could provide a patch
for the docs?


Sure, I will make a patch for this. Please wait a moment.


A patch to fix this problem is attached.
Please take a look.

Regards,
--
NAGAYASU Satoshi 
*** ecpg.sgml.orig  2010-05-13 09:55:05.0 +0900
--- ecpg.sgml   2010-08-10 12:21:42.0 +0900
***
*** 4791,4796 
--- 4791,4816 
  
  
   
+   0 (ECPG_NO_ERROR)
+   
+
+ (SQLSTATE 0)
+   
+  
+ 
+ 
+ 
+  100 (ECPG_NOT_FOUND)
+  
+   
+This is a harmless condition indicating that the last command
+retrieved or processed zero rows, or that you are at the end of
+the cursor.  (SQLSTATE 02000)
+   
+  
+ 
+ 
+  
-12 (ECPG_OUT_OF_MEMORY)

 
***
*** 4883,4889 
  
  
  
!  -207 (ECPG_CONVERT_BOOL)
   

 This means the host variable is of type bool and
--- 4903,4957 
  
  
  
!  -207 (ECPG_NUMERIC_FORMAT)
!  
!   
!The host variable is of type numeric and the datum
!in the database is of another type and contains a value that
!cannot be interpreted as a numeric.
!(SQLSTATE 42804)
!   
!  
! 
! 
! 
!  -208 (ECPG_INTERVAL_FORMAT)
!  
!   
!The host variable is of type interval and the datum
!in the database is of another type and contains a value that
!cannot be interpreted as a interval.
!(SQLSTATE 42804)
!   
!  
! 
! 
! 
!  -209 (ECPG_DATE_FORMAT)
!  
!   
!The host variable is of type date and the datum in
!the database is of another type and contains a value that
!cannot be interpreted as a date.
!(SQLSTATE 42804)
!   
!  
! 
! 
! 
!  -210 (ECPG_TIMESTAMP_FORMAT)
!  
!   
!The host variable is of type timestamp and the
!datum in the database is of another type and contains a value
!that cannot be interpreted as a timestamp.
!(SQLSTATE 42804)
!   
!  
! 
! 
! 
!  -211 (ECPG_CONVERT_BOOL)
   

 This means the host variable is of type bool and
***
*** 4894,4900 
  
  
  
!  -208 (ECPG_EMPTY)
   

 The statement sent to the PostgreSQL
--- 4962,4968 
  
  
  
!  -212 (ECPG_EMPTY)
   

 The statement sent to the PostgreSQL
***
*** 4906,4912 
  
  
  
!  -209 (ECPG_MISSING_INDICATOR)
   

 A null value was returned and no null indicator variable was
--- 4974,4980 
  
  
  
!  -213 (ECPG_MISSING_INDICATOR)
   

 A null value was returned and no null indicator variable was
***
*** 4916,4922 
  
  
  
!  -210 (ECPG_NO_ARRAY)
   

 An ordinary variable was used in a place that requires an
--- 4984,4990 
  
  
  
!  -214 (ECPG_NO_ARRAY)
   

 An ordinary variable was used in a place that requires an
***
*** 4926,4932 
  
  
  
!  -211 (ECPG_DATA_NOT_ARRAY)
   

 The database returned an ordinary variable in a place that
--- 4994,5000 
  
  
  
!  -215 (ECPG_DATA_NOT_ARRAY)
   

 The database returned an ordinary variable in a place that
***
*** 4936,4941 
--- 5004,5021 
  
  
  
+  -216 (ECPG_ARRAY_INSERT)
+  
+   
+The value could not be inserted into the array.(This is
+disabled by #if 0 in
+ecpg.)
+(SQLSTATE 42804)
+   
+  
+ 
+ 
+ 
   -220 (ECPG_NO_CONN)
   

***
*** 4966,4971 
--- 5046,5063 
  
  
  
+  -239 (ECPG_INFORMIX_DUPLICATE_KEY)
+  
+   
+Duplicate key error, and a violation for the unique
+constraint (Informix compatible mode).
+(SQLSTATE 23505)
+
+   
+  
+ 
+ 
+ 
   -240 (ECPG_UNKNOWN_DESCRIPTOR)
   

***
*** 5018,5023 
--- 5110,5125 
  
  
  
+  -284 (ECPG_INFORMIX_SUBSELECT_NOT_ONE)
+  
+   
+A result of the subquery is not single row (Informix compatibie mode).
+(SQLSTATE 21000)
+   
+  
+ 
+ 
+ 
   -400 (ECPG_PGSQL)
   

***
*** 5050,5064 
  
  
  
!  100 (ECPG_NOT_FOUND)
   

!This is a harmless condition indicating that the last command
!retrieved or pro