[BUGS] PostgreSQL
When inserting a row into a table, if there is a varchar column and if in that column the value to be inserted is a zero length string (like ‘’), then instead of writing a null value, PostgreSQL writes that zero length string. We are able to do this with delphi which generates such sql insert phrases. We contacted Borland, but there was no answer. I don’t know if this is a bug, but I’m sure that inserting a null value instead of a zero length string would help us a lot.
Re: [BUGS] Bug #866: Cursor scrolling broken in 7.3.1 (works in 7.2.1)
Tom Lane wrote: > > [EMAIL PROTECTED] writes: > > Cursor scrolling broken in 7.3.1 (works in 7.2.1) > > That's a fairly sweeping claim. > > I have found a bug that explains this problem for the case where the > cursor retrieves a single row using a unique index. Have you seen it > happen in any other cases? > > regards, tom lane That was not meant as a claim, but only as a help to classify the bug - something is broken there. The text from the "long description" field of the bug report form describes what the problem actually is. I have checked the posted example modified for a non-unique index and the bug does not occur. It did not occur for me under any other circumstances yet. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #865: PostgreSQL 7.3 and 7.3.1 fails to compile
On Tue, 7 Jan 2003, Tom Lane wrote: > Apparently, our configure script thinks you have getopt_long(), but you > really don't. Can you look into the situation and figure out why > configure is confused? > > It surprises me that this would happen when 7.2 worked okay --- I don't > think we changed that configure test since 7.2. Are you sure nothing > changed on your machine since you last built 7.2? Yes, I'm sure. This is what happens when I run configure with the 7.2.3 source: root@dev# ./configure --with-perl --enable-syslog --with-maxbackends=256 --with-libraries=/usr/lib:/usr/local/lib/:/usr/local/lib/lpe | grep -i getopt checking for getopt.h... no checking for getopt_long... no And this is with 7.3.1 (run several minutes later on the same machine): root@dev# !./conf ./configure --with-perl --enable-syslog --with-maxbackends=256 --with-libraries=/usr/lib:/usr/local/lib/:/usr/local/lib/lpe | grep -i getopt checking for library containing getopt_long... -lgnugetopt checking getopt.h usability... no checking getopt.h presence... no checking for getopt.h... no checking for getopt_long... yes This is from config.log (in the 7.3.1 source): configure:9866: gcc -o conftest -pipe -L/usr/lib -L/usr/local/lib/ -L/usr/local/lib/lpe conftest.c -lz -lreadline -lcrypt -lgnugetopt -lcompat -lm -lutil >&5 configure:9869: $? = 0 configure:9872: test -s conftest configure:9875: $? = 0 configure:9885: result: yes I have confirmed the conftest.c which tests getopt_long in that section of the code does indeed complie without errors. I'm a bit stumped as to what to check next. -Dan ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Function round(double precision, integer) does not exists troublein 7.3.1, did work on 7.2.1
I am having trouble with a function round that used to work in 7.2.1 PostgreSQL was updated to 7.3.1 from 7.2.1, the data was re-loaded into 7.3.1 with no complaints from the DB engine but, at application run time, we do get the error: Function round(double precision, integer) does not exists Code executed and that worked fine in 7.2.1 is: select clientes.id_cliente, clientes.codigo_cliente, clientes.total, clientes.deuda, clientes_pagos, total_pagos, diferencia from ( select clientes.id_cliente, clientes.codigo_cliente, clientes.total, clientes.deuda, (clientes.total-clientes.deuda) as clientes_pagos, sum(sum) as total_pagos, round((clientes.total-clientes.deuda)-sum(sum),4) as diferencia from ( select codigo_cliente, sum(total_pago) from pagos where estatus!='C' group by codigo_cliente union select codigo_cliente, sum(total_nota) from notas_credito where estatus!='C' group by codigo_cliente ) as TT where codigo_cliente=clientes.codigo_cliente group by clientes.codigo_cliente, clientes.id_cliente, clientes.total, clientes.deuda, clientes_pagos ) as TT1 where diferencia>0; Question is, what changed in 7.3.1 in reference to the round function. Tom Lane stated in a previous post (attached below) that "There isn't a round(double, integer) function in 7.3 and there wasn't one in 7.2 either."I am not so sure that is the case in our installation. ¿ How it can be explained then that it worked fine in a stock install (rpm from RedHat Linux 7.3) of PostgreSQL 7.2.1 ? Are we missing something here...? Any comments or sugestions are welcome. Felipe Barousse > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Bug #835: round(double precision,integer) function in 7.3 does not work > Date: Wed, 4 Dec 2002 16:26:28 -0500 (EST) > > > Eugene von Niederhausern ([EMAIL PROTECTED]) reports a bug with a severity of >3 > The lower the number the more severe it is. > > Short Description > round(double precision,integer) function in 7.3 does not work > > Long Description > round(double precision,integer) does not work with 7.3. This function did work with >7.2.x. > > Sample Code > select round((extract(epoch from CURRENT_TIMESTAMP) - extract(epoch from >'2002-12-01'::timestamp))/60.0/60.0/24.0,2); /** does not work with 7.3 **/ > > select round((extract(epoch from CURRENT_TIMESTAMP) - extract(epoch from >'2002-12-01'::timestamp))/60.0/60.0/24.0); /** does work with 7.3 **/ > > select round(((extract(epoch from CURRENT_TIMESTAMP) - extract(epoch from >'2002-12-01'::timestamp))/60.0/60.0/24.0)::numeric,2); /** does work with 7.3 **/ > > No file was uploaded with this report > > > > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: Bug #835: round(double precision,integer) function in 7.3 does not work > Date: Wed, 04 Dec 2002 17:55:29 -0500 > > > > round(double precision,integer) function in 7.3 does not work > > There isn't a round(double, integer) function in 7.3, and there wasn't > one in 7.2 either. > > 7.3 forces you to write the cast to numeric explicitly. > > regards, signature.asc Description: This is a digitally signed message part
Re: [BUGS] Bug #864: MOD(RANDOM(),1.0) don't work in 7.3.1
[Tom Lane] | This is not a bug, but an intentional change: float->numeric isn't | an implicit cast anymore. Ah. I didn't find it in the "Observe the following incompatibilities" of the HISTORY file, so I imagined it could be unintentional. Thanks for replying! Sverre. -- [EMAIL PROTECTED]Computer Geek? Try my Nerd Quiz http://shh.thathost.com/http://nerdquiz.thathost.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] dropping user doesn't erase his rights.
> > Difficult to do, when those privileges might be recorded in > > databases you're not even connected to at the time of the drop. > > I belive it would be pretty difficult, but leaving it "just like > that" creates ssecurity breach (imagine someone droping user, > beliving that everytinh is o.k.), than someone else creates > different user but with keeping unused sysid (this might be the case > with system users and keeping system user-id with database user-id > the same) - which happens to be "not unused". i'm not sure if i'm > clear about it. Wouldn't an ON DELETE trigger on the system catalogs work? I'd think it would be possible to select the tables and groups that a user had privs to and iterate through each calling REVOKE. -sc -- Sean Chittenden msg05642/pgp0.pgp Description: PGP signature
Re: [BUGS] PPTP + Cisco - is it possible for RADIUS server to
Ruslan, I'm afraid that you sent your message to the PostgreSQL Bugs Mailing List, where we cannot help you with Cisco problems. Please try an appropriate Cisco mailing list. -Josh Berkus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #870: subselect returns more than one tuple where not possible
[EMAIL PROTECTED] writes: > Sometimes when running concurrent updates, the function fails with ERROR: More than >one tuple returned by a subselect used as an expression. Can't say much about this when you aren't showing us the concurrent-update sequence of operations. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Bug #870: subselect returns more than one tuple where not possible
Bors Folgmann ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
subselect returns more than one tuple where not possible
Long Description
I'm using postgresql 7.2.2 on RedHat Linux 8.0.
Inside a transaction (PL/pgSQL function) I use a subselect in an if.
IF (SELECT people - employed FROM planets WHERE pid=cur_pid) < crewCosts *
order THEN
RETURN false;
END IF;
Sometimes when running concurrent updates, the function fails with ERROR: More than
one tuple returned by a subselect used as an expression.
This is absolutley impossible since pid is SERIAL PRIMARY KEY of the planets table.
How is it possible that the select returns more than one tuple? Could it be a bug in
MVCC?
I can not understand the parse tree and plan, but I have added the debug output for
you.
greetings,
boris
Sample Code
Jan 10 20:37:03 ra postgres[7992]: [154] DEBUG: Abfrage: SELECT (SELECT people -
employed FROM planets WHERE pid= $1 ) < $2 * $3
Jan 10 20:37:03 ra postgres[7992]: [155-1] DEBUG: Parsebaum: { QUERY :command 1
:utility <> :resultRelation 0 :into <> :isPortal false :isBinary false :isTemp false
Jan 10 20:37:03 ra postgres[7992]: [155-2] :hasAggs false :hasSubLinks true :rtable
<> :jointree { FROMEXPR :fromlist <> :quals <>} :rowMarks () :targetList ({
Jan 10 20:37:03 ra postgres[7992]: [155-3] TARGETENTRY :resdom { RESDOM :resno 1
:restype 16 :restypmod -1 :resname ?column? :reskey 0 :reskeyop 0 :ressortgroupref 0
Jan 10 20:37:03 ra postgres[7992]: [155-4] :resjunk false } :expr { EXPR :typeOid 16
:opType op :oper { OPER :opno 97 :opid 0 :opresulttype 16 } :args ({ SUBLINK
Jan 10 20:37:03 ra postgres[7992]: [155-5] :subLinkType 4 :useor false :lefthand <>
:oper <> :subselect { QUERY :command 1 :utility <> :resultRelation 0 :into <>
Jan 10 20:37:03 ra postgres[7992]: [155-6] :isPortal false :isBinary false :isTemp
false :hasAggs false :hasSubLinks false :rtable ({ RTE :relname planets :relid 29883
Jan 10 20:37:03 ra postgres[7992]: [155-7] :subquery <> :alias <> :eref { ATTR
:relname planets :attrs ( "pid" "owner" "name" "distance" "type" "people"
Jan 10 20:37:03 ra postgres[7992]: [155-8] "employed" "fuel" "ore" "ship"
"updated" "tech_level" "ship_res" "people_res" "fuel_res" "ore_res"
"growth"
Jan 10 20:37:03 ra postgres[7992]: [155-9]"colonized" )} :inh true :inFromCl true
:checkForRead true :checkForWrite false :checkAsUser 0}) :jointree { FROMEXPR
Jan 10 20:37:03 ra postgres[7992]: [155-10] :fromlist ({ RANGETBLREF 1 }) :quals {
EXPR :typeOid 16 :opType op :oper { OPER :opno 96 :opid 0 :opresulttype 16 } :args ({
Jan 10 20:37:03 ra postgres[7992]: [155-11] VAR :varno 1 :varattno 1 :vartype 23
:vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1} { PARAM :paramkind 12 :paramid
1
Jan 10 20:37:03 ra postgres[7992]: [155-12] :paramname \ :paramtype 23 })}}
:rowMarks () :targetList ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23
Jan 10 20:37:03 ra postgres[7992]: [155-13] :restypmod -1 :resname ?column? :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { EXPR :typeOid 23 :opType op
Jan 10 20:37:03 ra postgres[7992]: [155-14] :oper { OPER :opno 555 :opid 0
:opresulttype 23 } :args ({ VAR :varno 1 :varattno 6 :vartype 23 :vartypmod -1
:varlevelsup 0
Jan 10 20:37:03 ra postgres[7992]: [155-15] :varnoold 1 :varoattno 6} { VAR :varno 1
:varattno 7 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 7})}})
Jan 10 20:37:03 ra postgres[7992]: [155-16] :groupClause <> :havingQual <>
:distinctClause <> :sortClause <> :limitOffset <> :limitCount <> :setOperations <>
Jan 10 20:37:03 ra postgres[7992]: [155-17] :resultRelations ()}} { EXPR :typeOid 23
:opType op :oper { OPER :opno 545 :opid 0 :opresulttype 23 } :args ({ PARAM
Jan 10 20:37:03 ra postgres[7992]: [155-18] :paramkind 12 :paramid 2 :paramname
\ :paramtype 23 } { PARAM :paramkind 12 :paramid 3 :paramname \
Jan 10 20:37:03 ra postgres[7992]: [155-19] :paramtype 21 })})}}) :groupClause <>
:havingQual <> :distinctClause <> :sortClause <> :limitOffset <> :limitCount <>
Jan 10 20:37:03 ra postgres[7992]: [155-20] :setOperations <> :resultRelations ()}
Jan 10 20:37:03 ra postgres[7992]: [156-1] DEBUG: Plan: { RESULT :startup_cost 0.00
:total_cost 0.01 :rows 1 :width 0 :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno
Jan 10 20:37:03 ra postgres[7992]: [156-2] 1 :restype 16 :restypmod -1 :resname
?column? :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { EXPR
:typeOid
Jan 10 20:37:03 ra postgres[7992]: [156-3] 16 :opType op :oper { OPER :opno 97 :opid
66 :opresulttype 16 } :args ({ PARAM :paramkind 15 :paramid 0 :paramname <>
Jan 10 20:37:03 ra postgres[7992]: [156-4] :paramtype 23 } { EXPR :typeOid 23
:opType op :oper { OPER :opno 545 :opid 171 :opresulttype 23 } :args ({ PARAM
:paramkind 12
Jan 10 20:37:03 ra postgres[79
[BUGS] PPTP + Cisco - is it possible for RADIUS server to allocate IPs?
Hello all, I have problem with Cisco - it do not accept (do not use) my Framed-IP-Address attribute, but only use Cisco's internal IP pools for allocating IPs for PPTP users. Is it possible for Cisco to accept RADIUS's Framed-IP-Address attribute to correct setting up IP address for incoming PPTP user? I have watched attributes recieved from NAS (Cisco) in accounting Stop packet, and had seen interesting seen: . . . Framed-Protocol = PPP Tunnel-Client-Endpoint:0 = "10.0.0.1" Framed-IP-Address = 10.10.0.1 . . . The 10.10.0.1. address - is (externel) IP, which used in NAT, and real client's IP content Tunnel-Client-Endpoint:0 attribute. I think it is a problem - Cisco use not Framed-IP-Address attribute as IP of end-user, but other. How to influence in this situation? Is it possible to correct such Cisco behaviour? Thanks a lot for any comments. -- best regards, Ruslan A Dautkhanov [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
