[BUGS] BUG or feature?
Hi.
Bug or feature?
CREATE FUNCTION upd (text, text) RETURNS text AS '
BEGIN
RETURN $1;
END
' LANGUAGE 'plpgsql';
SELECT upd('aaa','bbb');
aaa
SELECT upd(null,'bbb');
All seems ok, but how about next ?
SELECT upd('aaa',null);
--
ó Õ×ÁÖÅÎÉÅÍ, ÷ÁÝÅÎËÏ íÁËÓÉÍ,
îÉÖÅÇÏÒÏÄÓËÉÅ ÉÎÆÏÒÍÁÃÉÏÎÎÙÅ ÓÅÔÉ
(8312) 30-19-05, 34-00-02, 30-09-73
With best regards, Max Vaschenko,
Nizhny Novgorod Information Networks.
[BUGS] Problem when calling setObject on Timestamp column with JDBC driver
I'm having a problem doing a select on an Order with a where clause below, getting a preparedStatemtnt and calling preparedStatement.setObject(timeStamp); Its return nothing and I know there is a row with that orderDate. SQL: select OrderID,CustomerID,EmployeeID,OrderDate,RequiredDate,ShippedDate,ShipVia,Fre ight,ShipName,ShipAddress,ShipCity,ShipRegion,ShipPostalCode,ShipCountry from Orders where OrderDate=? Setting value: OrderDate 1996-07-07 23:00:00.0 Could there be a bug here?
[BUGS] JDBC driver throws unfriendly exceptions
POSTGRESQL BUG REPORT TEMPLATE Your name : Jered Floyd Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : x86 Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.17 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 Compiler used (example: gcc 2.8.0) : gcc 2.95.2 Please enter a FULL description of your problem: While using the JDBC driver: Attempting to access data from a ResultSet (with getXXX(), etc.) before calling ResultSet.next() causes a NullPointerException to be thrown at the deference of this_row[] at ResultSet.java:164. Yes, I'm a bonehead for trying to access the row data before calling next(), but this isn't the ideal thing to have happen. The driver should catch this case (by checking this_row[] or catching the exception) and throw something more descriptive. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- After construcing a PreparedStatement ps: int i; ResultSet rs = ps.executeQuery(); if (rs != null) i = getInt(1); If you know how this problem might be fixed, list the solution below: - As I mention above, the driver should catch this case and throw a more descriptive exception. It's inappropriate and un-neighborly to go around throwing exceptions like NullPointerException or ArrayIndexOutOfBoundsException. I think (hope) the JDBC driver is a moving target, so I'll take a look at this issue when I move over to using 7.1beta (after I've beaten 7.0 into submission.)
[BUGS] 7.1beta4 problem on freebsd 4.2 with JSDK 1.1.8.
FreeBSD spot.pupworks.com 4.2-STABLE FreeBSD 4.2-STABLE #1: Sat Feb 3 15:45:14 EST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPOT i386 Using java SDK 1.1.8, which is the current "real" java in the freebsd ports tree, one can't compile the jdbc driver. The Implementation file mentions that "ant" has not been tested with 1.1.X, and suggests that the deprecated makefile will work. The errors below are from a java file, and occur whether one uses "gmake jdbc1" or "ant" to attempt to build the driver. spot% ant Searching for build.xml ... Buildfile: /usr/home/nrh/postgresql/postgresql-7.1beta4/build.xml jar: call: prepare: check_versions: driver: Configured build for the JDBC1 edition driver. compile: [javac] Compiling 1 source file to /usr/home/nrh/postgresql/postgresql-7.1beta4/src/interfaces/jdbc/build [javac] /usr/home/nrh/postgresql/postgresql-7.1beta4/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:284: Missing term. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] /usr/home/nrh/postgresql/postgresql-7.1beta4/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:284: Invalid expression statement. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] /usr/home/nrh/postgresql/postgresql-7.1beta4/src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java:284: ';' expected. [javac] if (result != null) && ((org.postgresql.ResultSet)result.reallyResultSet()) [javac] ^ [javac] 3 errors BUILD FAILED /usr/home/nrh/postgresql/postgresql-7.1beta4/src/interfaces/jdbc/build.xml:82: Compile failed, messages should have been provided. Total time: 4 seconds
[BUGS] byteain() doesn't parse correctly
POSTGRESQL BUG REPORT TEMPLATE Your name : Jered Floyd Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : x86 Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.17 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 Compiler used (example: gcc 2.8.0) : gcc 2.95.2 Please enter a FULL description of your problem: byteain() in backend/utils/adt/varlena.c is just wrong. It can't parse '\\', claiming 'Bad input string for type bytea'. No, really. More curious is that it can't handle '\134' either, implying that multiple levels of parsing are going on. But, it *can* parse '' as \\. This boggles the mind. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- SELECT '\\'::bytea; SELECT '\134'::bytea; SELECT ''::bytea; If you know how this problem might be fixed, list the solution below: - This routine is cherry fondue; extremely nasty, but we can't prosecute for that. It needs a good rewrite, and an audit of the parse chain in general wouldn't hurt. As with the previous 2 bugs, I suspect this is something I'll just do when I port my 7.0.3 routines for making BYTEAs more first-class citizens to 7.1. I'd be tickled if you beat me to it, though.
[BUGS] JDBC driver doesn't allow access to BYTEA types via get/setBytes()
POSTGRESQL BUG REPORT TEMPLATE Your name : Jered Floyd Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : x86 Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.17 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3 Compiler used (example: gcc 2.8.0) : gcc 2.95.2 Please enter a FULL description of your problem: The JDBC driver doesn't provide an interface to access BYTEA types, as get/setBytes() have been co-opted to operate on BLOBs. This is frustrating as JDBC says this is for operating on both VARBINARY and LONGVARBINARY SQL92 types, and BYTEA is the closest to VARBINARY that we've got. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Performing an update to a BYTEA field value set with setBytes() yields: "Attribute 'vhandle' is of type 'bytea' but expression is of type 'int4'" because the JDBC driver is trying to store the OID for a LOB it created. If you know how this problem might be fixed, list the solution below: - get/setBytes() should be extended to handle both BYTEA and OID types as appropriate. I think (hope) the JDBC driver is a moving target, so I'll take a look at this issue when I move over to using 7.1beta (after I've beaten 7.0 into submission.)
Re: [BUGS] BUG or feature?
Max Vaschenko <[EMAIL PROTECTED]> writes:
> All seems ok, but how about next ?
> SELECT upd('aaa',null);
>
This is fixed in 7.1. It's unfixable in prior releases because the
old function manager only maintained one argument-is-null flag for a
function call ... so *all* the arguments are taken as null if any are.
regards, tom lane
Re: [BUGS] byteain() doesn't parse correctly
Jered Floyd <[EMAIL PROTECTED]> writes: > More curious is that it can't handle '\134' either, implying that > multiple levels of parsing are going on. You're right, there are multiple levels of parsing going on. The string-literal parser gets first crack before the type-specific input converter does. If you don't allow for that when counting backslashes etc, you'll get confused for sure. regards, tom lane
[BUGS] Re: round - timestamp bug
Gonzalo Arana wrote:
>
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
> Your name : Gonzalo Arana
> Your email address : [EMAIL PROTECTED]
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel Pentium III
>
> Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.12-20 ELF
> (libc-2.1.2)
>
> PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3
>
> Compiler used (example: gcc 2.8.0) : egcs-2.91.66
>
> Please enter a FULL description of your problem:
>
>
> It seems that there is a problem when retrieving a timestamp value (rounding).
>
> NO minute has 61 seconds. Am I wrong?
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
>
> radius=# create table x (x timestamp);
> CREATE
> radius=# insert into x (x) values ('Tue 23 Jan 21:38:59.997 2001');
> INSERT 619178 1
> radius=# select * from x;
> x
> -
> Tue 23 Jan 21:38:60.00 2001 ART
> (1 row)
>
> If you know how this problem might be fixed, list the solution below:
> -
>
> Ugly patch to scripts:
>
> radius=# select to_char(x,'Dy DD Mon HH24:MI:SS ') from x;
> to_char
> --
> Tue 23 Jan 21:38:59 2001
> (1 row)
>
> Of course, you'll lose the fraction of seconds otherwise are available.
Actually, such leap-seconds are possible. This can happen when your
timebase is a NTP time server such as the Naval Observatory, etc. They
are used for micro adjustments to adjust clock to siderial (celestial)
time. I have had to write date+time classes in C++ which could handle
this exact situation... X-). The fact that Postgres-SQL can handle this
is probably a good thing.
-Bill Boyle
Re: [BUGS] Re: round - timestamp bug
> Gonzalo Arana wrote:
>> radius=# create table x (x timestamp);
>> CREATE
>> radius=# insert into x (x) values ('Tue 23 Jan 21:38:59.997 2001');
>> INSERT 619178 1
>> radius=# select * from x;
>> x
>> -
>> Tue 23 Jan 21:38:60.00 2001 ART
>> (1 row)
This is just a display artifact. The value stored is actually ... 59.997
(plus or minus a little bit from floating-point roundoff error) but the
seconds value is rounded to two digits during display.
I have suggested in the past that it'd be better to round the floating
value to two fractional digits before we break it down to date/hh/mm/ss,
rather than after, but that suggestion seems to have fallen on deaf
ears.
regards, tom lane
[BUGS] Re: round - timestamp bug
> > It seems that there is a problem when retrieving a timestamp value (rounding). > > NO minute has 61 seconds. Am I wrong? > > radius=# select timestamp 'Tue 23 Jan 21:38:59.997 2001'; > > - > > Tue 23 Jan 21:38:60.00 2001 ART > Actually, such leap-seconds are possible. This can happen when your > timebase is a NTP time server such as the Naval Observatory, etc. They > are used for micro adjustments to adjust clock to siderial (celestial) > time. I have had to write date+time classes in C++ which could handle > this exact situation... X-). The fact that Postgres-SQL can handle this > is probably a good thing. All true, but the underlying problem in this case is not that "59.997" or even "60.0" is accepted, but that it is displayed as "60.0" (although a value of "60" does show up during leap second transitions, it is only as a placeholder while waiting for the next "official minute" to start ;). The original report did not give complete platform details, but in my recollection the *only* recent cases of this display problem come from Mandrake systems which are built with overly aggressive compiler optimization options. Check and verify that you are not using "-O n" and "-fast-math" together when compiling PostgreSQL. As an aside, the Mandrake folks are aware of this problem in their distro and have recently fixed their version of the spec file; hopefully we will get this folded back into Lamar's spec file before 7.1 goes out. - Thomas
Re: [BUGS] Re: round - timestamp bug
Thomas Lockhart <[EMAIL PROTECTED]> writes: > The original report did not give complete platform details, but in > my recollection the *only* recent cases of this display problem come > from Mandrake systems which are built with overly aggressive compiler > optimization options. No, the behavior is not platform-specific. I'm on HP-PA: regression=# select 'Tue 23 Jan 21:38:59.997 2001'::timestamp; ?column? --- 2001-01-23 21:38:60.00-05 (1 row) The problem is that we round the fractional seconds part to two digits only after we've separated seconds from the other fields. (I imagine the code is not even doing that explicitly, but leaving it to sprintf to do so.) It would work better if we rounded the entire floating timestamp value to two fractional digits before we break it down, eg with tstamp = rint(tstamp * 100.0) / 100.0; regards, tom lane
Re: [BUGS] byteain() doesn't parse correctly
Jered Floyd <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> You're right, there are multiple levels of parsing going on. The >> string-literal parser gets first crack before the type-specific >> input converter does. If you don't allow for that when counting >> backslashes etc, you'll get confused for sure. > Argh. This is really bad. This means, for example, that I can't have > NULs in my bytea, which was the whole reason I was using bytea to > begin with. Actually, maybe not. Sure you can. You just have to write them as \000, which actually will be written \\000 to get through the string-literal parser. It's not a real *convenient* notation, I agree, but it works. There has been talk of providing alternate paths, such as functions that would convert bytea to and from other textual representations like base64. Nothing's been done yet though. regards, tom lane
Re: [BUGS] Re: round - timestamp bug
> No, the behavior is not platform-specific. I'm on HP-PA: Hmm. Don't see that on my Linux box :( We don't have regression tests which cover this case? > The problem is that we round the fractional seconds part to two digits > only after we've separated seconds from the other fields. (I imagine > the code is not even doing that explicitly, but leaving it to sprintf > to do so.) It would work better if we rounded the entire floating > timestamp value to two fractional digits before we break it down, > eg with > tstamp = rint(tstamp * 100.0) / 100.0; Sure, that's a possibility. There is already a macro to help do that sort of thing, but I've not jumped to this solution since we probably should allow some kind of variable precision on date/time types. - Thomas
Re: [BUGS] postmaster grows
Max Vaschenko <[EMAIL PROTECTED]> writes: > [ postmaster leaks memory when using password authentication ] You are right! The postmaster leaks memory to the tune of a few dozen bytes per password authentication attempt. I'm surprised no one noticed this before. People must not be using password auth under heavy load... Attached is a patch to fix it in 7.0.*. regards, tom lane *** src/backend/libpq/crypt.c.orig Sat Jul 17 16:17:01 1999 --- src/backend/libpq/crypt.c Wed Feb 7 18:40:01 2001 *** *** 59,64 --- 59,65 bufsize = strlen(pwdfilename) + strlen(CRYPT_PWD_RELOAD_SUFX) + 1; rpfnam = (char *) palloc(bufsize); snprintf(rpfnam, bufsize, "%s%s", pwdfilename, CRYPT_PWD_RELOAD_SUFX); + pfree(pwdfilename); return rpfnam; } *** *** 79,84 --- 80,87 pwdfile = AllocateFile(filename, "rb"); #endif + pfree(filename); + return pwdfile; } *** *** 131,136 --- 134,140 filename = crypt_getpwdreloadfilename(); result = unlink(filename); + pfree(filename); /* * We want to delete the flag file before reading the contents of the
[BUGS] Problem displaying functions and views in 7.1b3
() reports a bug with a severity of 3 The lower the number the more severe it is. Short Description Problem displaying functions and views in 7.1b3 Long Description BUG REPORT Version: 7.1 beta 3 Platform: SuSE Linux 7.0 Installation: Mixed; 7.0.3 & 7.1 beta parallel install Urgency: Cosmetic Location: psql and pgaccess I've noticed a problem displaying Functions and Views via PSQL in 7.1b3. When one attempts to display views (\dv), one gets nothing. When one displays functions, one gets the opposite ... the command lists *all* functions, including all builtins, not just user-defined functions. Both views and functions operate normally when called via sql, however. Please note that I may, due to my parallel install, be accidentally using ver. 7.0.3 psql with the 7.1b3 Postgres. If so, I;d like to know. Sample Code No file was uploaded with this report
Re: [BUGS] Problem displaying functions and views in 7.1b3
[EMAIL PROTECTED] writes: > I've noticed a problem displaying Functions and Views via PSQL in > 7.1b3. When one attempts to display views (\dv), one gets nothing. This is a symptom of using 7.0.* or older psql with current server. > When one displays functions, one gets the opposite ... the command lists > *all* functions, including all builtins, not just user-defined > functions. Uh, has it ever done differently? \df certainly appears to me to list all functions in 7.0.*. regards, tom lane
Re: [BUGS] Problem displaying functions and views in 7.1b3
Tom Lane wrote:
>
> > When one displays functions, one gets the opposite ... the command lists
> > *all* functions, including all builtins, not just user-defined
> > functions.
>
> Uh, has it ever done differently? \df certainly appears to me to list
> all functions in 7.0.*.
>
There's the following code in src/bin/pgaccess/lib/mainlib.tcl
wpg_select $CurrentDB "select proname from pg_proc where
oid>$maxim order by proname" rec {
where maxim(the oid of "template1" database) is 1 in 7.1.
Regards,
Hiroshi Inoue
Re: [BUGS] Problem displaying functions and views in 7.1b3
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Uh, has it ever done differently? \df certainly appears to me to list
>> all functions in 7.0.*.
> There's the following code in src/bin/pgaccess/lib/mainlib.tcl
> wpg_select $CurrentDB "select proname from pg_proc where
> oid>$maxim order by proname" rec {
> where maxim(the oid of "template1" database) is 1 in 7.1.
Okay, so pgaccess has got a behavior change ... but the bug report was
about psql, or so I thought.
We can easily change pgaccess to do this correctly for 7.1, but then it
will fail completely on older releases (there was no datlastsysoid column
in pg_database before). Is backward compatibility a design concern for
pgaccess, or not?
regards, tom lane
Re: [BUGS] Problem displaying functions and views in 7.1b3
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Uh, has it ever done differently? \df certainly appears to me to list
> >> all functions in 7.0.*.
>
> > There's the following code in src/bin/pgaccess/lib/mainlib.tcl
> > wpg_select $CurrentDB "select proname from pg_proc where
> > oid>$maxim order by proname" rec {
> > where maxim(the oid of "template1" database) is 1 in 7.1.
>
> Okay, so pgaccess has got a behavior change ... but the bug report was
> about psql, or so I thought.
>
Similar bug reports have been floating around ODBC, pgaccess,
psql etc and so people seem to be confused.
> We can easily change pgaccess to do this correctly for 7.1, but then it
> will fail completely on older releases (there was no datlastsysoid column
> in pg_database before). Is backward compatibility a design concern for
> pgaccess, or not?
>
How about the following though the result is different from
datlastsysoid ?
select max(oid) from pg_database where datname like 'template%';
Regards,
Hiroshi Inoue
Re: [BUGS] Problem displaying functions and views in 7.1b3
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > How about the following though the result is different from > datlastsysoid ? > select max(oid) from pg_database where datname like 'template%'; Too lax --- suppose someone makes a database named 'template3' ? Even if we restricted the pattern to 'template[01]', it would fail if someone deleted and rebuilt template1, which is a supported operation now. If we want to do it in a backwards-compatible fashion in pgaccess, I'd recommend trying the datlastsysoid approach and then the other way if that fails. I'm just wondering if anyone cares ... regards, tom lane
