Re: [BUGS] BUG #1578: ::bit(n) behaves "differently" if applied to bit
Bruce Momjian writes: > ... Though this is slightly inconsistent in how it works with a > bit string, it does seem the most useful approach. Also, this is a behavior that we changed in 8.0 in response to previous complaints. Before changing it again, I'd want to see a pretty detailed analysis of either (1) why the previous complainers were idiots, or (2) why this change is still compatible with what they asked for ;-) Where relevant, comments on SQL spec compliance would help the argument too. I don't think the spec defines any bit<->integer conversions, but it definitely addresses the issue of converting from bit(m) to bit(n). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1578: ::bit(n) behaves "differently" if applied to bit
Celia McInnis wrote: > > The following bug has been logged online: > > Bug reference: 1578 > Logged by: Celia McInnis > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.1 > Operating system: Linux > Description:::bit(n) behaves "differently" if applied to bit strings > than integers. > Details: > > It's probably not good (at least for mathematicians!) to have the following > give different results: > > select B'1110110101'::bit(6); > select B'1110110101'::integer::bit(6); > > The first gives 110101 (the 6 least significant bits). > The second gives 111011 (the 6 most significant bis). I ran some tests on your example: test=> select B'1'::bit(6); bit 10 (1 row) test=> select B'1'::integer::bit(6); bit 01 (1 row) test=> select B'10'::bit(6); bit 10 (1 row) test=> select B'10'::integer::bit(6); bit 10 (1 row) >From this, it seems the issue is how ::bit should pad a string if the number of bits supplied in the string is less than the length specified. I think it is behaving correctly to pad with zeros on the end because it is not a number but a string of bits. What happens with the ::integer cast is that the string is expanded to 32 bits, and then cast to only six. An argument could be made that it should then take the left 6 bits and they should all be 0's. In fact, that's what it does if you supply just a string with zero padding: test=> select B'0010'::bit(6); bit 00 (1 row) test=> select B'0010'::integer::bit(6); bit 10 (1 row) Looking at the code, backend/utils/adt/varbit.c::bitfromint4 is a special function just for converting to bit from int4, and this piece of the code seems most significant: /* drop any input bits that don't fit */ srcbitsleft = Min(srcbitsleft, destbitsleft); And, I think it is done this way because int4 has a fixed length, so it is pretty hard to set the high 3 bits in an int32 value, so the way the code works is it assumes you want the lower X bits during the conversion. Though this is slightly inconsistent in how it works with a bit string, it does seem the most useful approach. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1656: ResultSetMetaData.getColumnDisplaySize()
On Tue, 10 May 2005, Sergio Lob wrote: > Bug reference: 1656 > PostgreSQL version: 8.0.1 > Description:ResultSetMetaData.getColumnDisplaySize() returns value > -1 > Details: > > ResultSetMetaData.getColumnDisplaySize() returns value -1 for several > columns of answer set generated by DatabaseMetaData.getTables() method. ResultSetMetaData.getColumnDisplaySize() returns -1 for any column that has an unknown size. Consider the REMARKS column of getTables(). This data comes from the system's pg_description.description column which is of type "text". There is no defined length for this, so we have decided to return -1. > Additionally, I don't understand why the data type of column 1 is described > as "OTHER", as opposed to all the other columns, which are of type "VARCHAR" > (attained through ResultSetMetaData.getColumnType() method). > TABLE_CAT is generated by an untyped "SELECT NULL", we should probably cast this to name, or report the currently connected database name here. Kris Jurka ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug Report with Postgres 7.4 on AIX 5.3
Vincent Vanwynsberghe <[EMAIL PROTECTED]> writes: > In our platform the sizeof of struct sockaddr_un is 1025 and the sizeof of > SockAddr is 144. Doesn't AIX provide struct sockaddr_storage? That struct has to be at least as large as any of the other platform-specific sockaddr structs. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1656: ResultSetMetaData.getColumnDisplaySize() returns value -1
The following bug has been logged online: Bug reference: 1656 Logged by: Sergio Lob Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Linux edared30 2.4.21-27.0.4.ELsmp #1 SMP Sat Apr 16 18:43:06 EDT 2005 i686 i686 Description:ResultSetMetaData.getColumnDisplaySize() returns value -1 Details: ResultSetMetaData.getColumnDisplaySize() returns value -1 for several columns of answer set generated by DatabaseMetaData.getTables() method. Columns 1,4 and 5 of answer set (columns "table_cat", "table_type", and "remarks" respectively) are described to be of length -1. The other 2 columns of the answer set (columns 2 & 3) are described to be of length 64, which makes more sense. Is there a reason why -1 is returned for these columns? Additionally, I don't understand why the data type of column 1 is described as "OTHER", as opposed to all the other columns, which are of type "VARCHAR" (attained through ResultSetMetaData.getColumnType() method). Thanks, Sergio Lob ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Bug Report with Postgres 7.4 on AIX 5.3
Dear Support,
We try to install Postgres 7.4 on AIX 5.3 (IBM,9111-520).
The compilation is good and we are able to start the postmaster.
When we try to start the psql we got the following error :
FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
We run the psql under the AIX debugger dbx and our conclusions are the
following :
In the file fe-connect.c we try to copy a area of 1025 in the
conn->raddr.addr area but the size of that area is only 144.
The result is a corruption of the pg_conn structure
+1175 /* Remember current address
for possible error msg */
+1176 memcpy(&conn->raddr.addr,
addr_cur->ai_addr,
+1177
addr_cur->ai_addrlen);
The addr_cur->ai_addrlen is set with the sizeof(struct sockaddr_un) in the
file ip.c.
In the file libpq-int.h the structure pg_conn contains 2 fields SockAddr
* PGconn stores all the state data associated with a single connection
* to a backend.
*/
struct pg_conn
{
...
SockAddrladdr; /* Local address */
SockAddrraddr;
...
}
The structure SockAddr is defined in the file pqcomm.h
typedef struct
{
struct sockaddr_storage addr;
ACCEPT_TYPE_ARG3 salen;
} SockAddr;
On Our AIX 5.3 the sockaddr_un is defined in the file /usr/include/sys/un.h
#if defined(COMPAT_43) && !defined(_KERNEL)
struct sockaddr_un {
ushort_tsun_family; /* AF_UNIX */
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
support long user names */
};
#else
struct sockaddr_un {
uchar_t sun_len;/* sockaddr len including null */
sa_family_t sun_family; /* AF_UNIX */
charsun_path[PATH_MAX]; /* changed from 104 to PATH_MAX to
support long user names */
};
#endif /* COMPAT_43 && !_KERNEL */
PATH_MAX is defined in the file /usr/include/sys/limits.h
#if _POSIX_C_SOURCE >= 200112L && !(defined _ALL_SOURCE) ||
defined(_PATHMAX_HAS_NULL)
#define PATH_MAX1024/* max number of bytes in a
pathname.
includes a terminating null */
#else
#define PATH_MAX1023
#endif
In our platform the sizeof of struct sockaddr_un is 1025 and the sizeof of
SockAddr is 144.
In conclusion the instructions done in the function PQconnectPoll cause a
memory overflow !!!
+1175 /* Remember current address
for possible error msg */
+1176 memcpy(&conn->raddr.addr,
addr_cur->ai_addr,
+1177
addr_cur->ai_addrlen);
Are you aware about this problem ?
Could you give us a way to solve the problem ?
Kind Regards,
Vincent Vanwynsberghe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
