Re: [BUGS] BUG #4638: Bug with Geometry in Array

[Kris Jurka]

On Mon, 2 Mar 2009, "Dr. Björn Weitzig" wrote:


I can't find any "modified JDBC driver", only the "JDBC extension"
postgis.jar (your link), which I use und which doesn't help. postgis.jar
seems to be an add-on to the default JDBC driver, not an replacement.
I use postgis_1.3.5.jar with postgresql-8.3-603.jdbc3.jar



Right, postgis.jar is just an addon, and it's really a bug in the main 
JDBC driver.  I have put in a fix for this bug into the JDBC driver for 
the next release.  I've put up a copy of it here, and it should fix things 
for you.


http://ejurka.com/pgsql/jars/arrdim/

Kris Jurka

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4684: lastval in function

[Jaime Casanova]

On Mon, Mar 2, 2009 at 12:21 PM, Tom Lane  wrote:
>
> Before considering complicating the definition of lastval, I'd vote
> for removing it entirely.  It's a foot-gun and will never be anything
> but.
>

+1


-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4684: lastval in function

[Tom Lane]

Chris Browne  writes:
> I'm not sure I'd *want* to have a more-sophisticated scoping mechanism
> for this.

We already have an appropriate language-level solution for this: it's
called INSERT RETURNING.

The fact is that lastval was invented to aid in porting brain-dead
mysql applications that weren't going to do anything as complicated
as execute commands that might involve more than one nextval call.
If there is any remote possibility that your app might have to deal
with such a thing, you shouldn't be using lastval.

Before considering complicating the definition of lastval, I'd vote
for removing it entirely.  It's a foot-gun and will never be anything
but.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4687: PostgreSQL website won't let me register

[Tihamer Toth-Fejel]

The following bug has been logged online:

Bug reference:  4687
Logged by:  Tihamer Toth-Fejel
Email address:  tihamer.toth-fe...@gd-ais.com
PostgreSQL version: n/a (web page)
Operating system:   n/a
Description:PostgreSQL website won't let me register
Details: 

After I put in my name address, and password, I hit password, and it just
returns me the same page.
(this is after I once gave it a mismatched password).
What do I do?
I'm running firefox 3.0.6.

Tihamer T. Toth-Fejel
tihamer.toth-fe...@gd-ais.com
General Dynamics Advanced Information Systems
Michigan Research and Development Center
(734) 480-5404

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4684: lastval in function

[Chris Browne]

Andreas  writes:
> Heikki Linnakangas schrieb:
>> andreas wrote:
>>> if nextval is used inside a function in a insertstatement, you get always
>>> the value from inside the last function. but i expected, that lastval()
>>> deliver the value from the insertstatement. i think, this should
>>> clearify in
>>> the documentation, or better fixed that the nextval from an
>>> insertstatement
>>> is called after the functioncalls.
>>
>> Well, others might expect the opposite, like existing
>> applications. Want to suggest wording for the documentation?
>
> Yes, existing applications might be involved. But i think, this is a
> very rare situation. But if someone use an insertstatement with a
> functioncall, but the function do NOT use nextval, and he use lastval to
> estimate the last inserted value he has no problems. But if then someone
> change the function so the function use nextval then the application
> crashes. So i think it is much more better to change the behavior,
> because this is what i expect. And i think, this is what others
> expect too.

Someone recently reported this issue as a possible bug in Slony-I;
they had written their application to use lastval() to capture
sequence values, and then, when they introduced replication, they
started capturing values of a sequence Slony-I uses to control *its*
operations.

You'd experience the same problem with any similar sort of "after"
trigger that was added to do logging; any kind of logging system that
uses sequences is liable to break usage of lastval().

This actually feels like it's a global versus dynamic/lexical scope
problem .

PostgreSQL is capturing *all* the sequence updates for the connection,
where the application would apparently prefer to only see those that
it *wants* to see.  I'm not sure whether lexical or dynamic scope
better reflect what might be desired.

However, the notion of there being some kind of more-local scope is
the big deal, something which PostgreSQL does not support.

I'm not sure I'd *want* to have a more-sophisticated scoping mechanism
for this.
-- 
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/nonrdbms.html
Rules of the Evil Overlord #177.  "If a scientist with a beautiful and
unmarried  daughter  refuses to  work  for me,  I  will  not hold  her
hostage. Instead, I  will offer to pay for her  future wedding and her
children's college tuition." 

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4684: lastval in function

[Andreas]

Heikki Linnakangas schrieb:

andreas wrote:

if nextval is used inside a function in a insertstatement, you get always
the value from inside the last function. but i expected, that lastval()
deliver the value from the insertstatement. i think, this should 
clearify in
the documentation, or better fixed that the nextval from an 
insertstatement

is called after the functioncalls.


Well, others might expect the opposite, like existing applications. Want 
to suggest wording for the documentation?


Yes, existing applications might be involved. But i think, this is a
very rare situation. But if someone use an insertstatement with a
functioncall, but the function do NOT use nextval, and he use lastval to
estimate the last inserted value he has no problems. But if then someone
change the function so the function use nextval then the application
crashes. So i think it is much more better to change the behavior,
because this is what i expect. And i think, this is what others
expect too.

Andreas

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #4686: There is not enough memory to complete this operation

[Jonas R. Pacheco]

The following bug has been logged online:

Bug reference:  4686
Logged by:  Jonas R. Pacheco
Email address:  supo...@migrate.com.br
PostgreSQL version: 8.3.5
Operating system:   Windows Server 2003
Description:There is not enough memory to complete this operation
Details: 

During use of the application, which connects to the database via ODBC, from
time to time, appears the following message: There is not enough memory to
complete this operation. Change some parameter in postgresql.conf,
particularly the shared buffers, however, this only decreased the frequency
at which the error occurs.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4638: Bug with Geometry in Array

[Dr. Björn Weitzig]

Thank you for your fast reply.

I can't find any "modified JDBC driver", only the "JDBC extension"
postgis.jar (your link), which I use und which doesn't help. postgis.jar
seems to be an add-on to the default JDBC driver, not an replacement.
I use postgis_1.3.5.jar with postgresql-8.3-603.jdbc3.jar

It would be great if you can show me where to get the "modified JDBC
driver".
As PostGIS is a common extension to PostgreSQL, wouldn't it be good to
handle this case in the default JDBC driver?

Thank you,
Bjoern Weitzig

On 2009-02-03 17:43, Tom Lane wrote:
> "Bjoern Weitzig" writes:
> > I use arrays like "select array(select n from a)". This works well
except of
> > the case with geometry as datatype.
>
> The geometry type intentionally uses ':' as the array delimiter. It
> seems like a good bet that the JDBC driver you're using doesn't expect
> anything but ',' as array delimiter. I checked with the postgis-devel
> list and they recommend using the modified JDBC driver that's
> distributed with postgis.
>
http://postgis.refractions.net/documentation/manual-1.3.6SVN/ch04.html#id2726248
>
> regards, tom lane
>
>

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4684: lastval in function

[Heikki Linnakangas]

andreas wrote:

if nextval is used inside a function in a insertstatement, you get always
the value from inside the last function. but i expected, that lastval()
deliver the value from the insertstatement. i think, this should clearify in
the documentation, or better fixed that the nextval from an insertstatement
is called after the functioncalls.


Well, others might expect the opposite, like existing applications. Want 
to suggest wording for the documentation?


To get the id of the row inserted, use INSERT RETURNING. Or currval('bla2').

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs