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);
--
ó Õ×ÁÖÅÎÉÅÍ, ÷ÁÝÅÎËÏ íÁËÓÉÍ,
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,ShippedDat
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jered Floyd
Your email address : [EMAIL PROT
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 t
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jered Floyd
Your email address : [EMAIL PROT
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jered Floyd
Your email address : [EMAIL PROT
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 a
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
Gonzalo Arana wrote:
>
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
> Your name : Gonzalo Arana
> Your email addres
> 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
> > 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 p
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
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
> 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 imagi
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 passwor
() 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: Cosmeti
[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 co
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 fo
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 wh
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
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 't
21 matches
Mail list logo
