Disallow premature is broken

Disallow premature is broken

am 25.01.2006 23:50:29 von Ludek Finstrle

Hello,

Dmitry pointed me that Disallow premature is next broken feature.
I found next difference between old driver and new one.

When there are more statements in one (using semicolon ';') that
07.03 driver returns more results QResultClass. The 08.01 one
returns only one QResultClass. The example of such mutlistatement is:
"BEGIN; SELECT * FROM table; COMMIT". The old driver returns 3
QResultClass but 08.01 driver returns only last result (from COMMIT)
QResultClass.
This behaviour breaks Disallow premature so it fails with access
violation. I can fix it becouse now we are using PQgetResult. But I'm
not sure if it doesn't break something another.

I could fix a little the Disallow premature so it doesn't fail
with access violation but it doesn't work at all.

What do you think? How do we want change the behaviout before
releasing new stable release? I'm not sure. There is no much time
for testing new behaviour. The multistatements hasn't been reported
yet by users. It seems this feature isn't widely used.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Disallow premature is broken

am 27.01.2006 10:39:05 von Dave Page

=20

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org=20
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Ludek Finstrle
> Sent: 25 January 2006 22:50
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] Disallow premature is broken
>=20
> Hello,
>=20
> Dmitry pointed me that Disallow premature is next broken feature.
> I found next difference between old driver and new one.
>=20
> When there are more statements in one (using semicolon ';') that
> 07.03 driver returns more results QResultClass. The 08.01 one
> returns only one QResultClass. The example of such mutlistatement is:
> "BEGIN; SELECT * FROM table; COMMIT". The old driver returns 3
> QResultClass but 08.01 driver returns only last result (from COMMIT)
> QResultClass.
> This behaviour breaks Disallow premature so it fails with access
> violation. I can fix it becouse now we are using PQgetResult. But I'm
> not sure if it doesn't break something another.
>=20
> I could fix a little the Disallow premature so it doesn't fail
> with access violation but it doesn't work at all.
>=20
> What do you think? How do we want change the behaviout before
> releasing new stable release? I'm not sure. There is no much time
> for testing new behaviour. The multistatements hasn't been reported
> yet by users. It seems this feature isn't widely used.

Yuck. My first thought is that we need to try to parse the query string
and extract the last result returning query, but perhaps we would be
better to look at returning multiple results again.

In the short term though, I say just stop it crashing and let's get a
release out seeing as Tom is getting antsy about FC5 :-)

Can you produce a final 08.01.0108 dev build, and I'll look to build
08.01.0200 on say Tuesday/Wednesday? Does that work for you Tom?

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Disallow premature is broken

am 27.01.2006 10:51:42 von Ludek Finstrle

> > What do you think? How do we want change the behaviout before
> > releasing new stable release? I'm not sure. There is no much time
> > for testing new behaviour. The multistatements hasn't been reported
> > yet by users. It seems this feature isn't widely used.
>
> In the short term though, I say just stop it crashing and let's get a
> release out seeing as Tom is getting antsy about FC5 :-)

Ok. I agree. (what is the word "antsy" I can't find it in vocabulary).

> Can you produce a final 08.01.0108 dev build, and I'll look to build
> 08.01.0200 on say Tuesday/Wednesday? Does that work for you Tom?

I'll try to create the patch for Disallow Premature today. But I'm not
sure if I will have enough time for it. I have few time today and during
weekend :-(

What's the next deadline Tom? I ask to know how much I'm under pressure.
If we are too late I could sleep for a shorter time today.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Disallow premature is broken

am 27.01.2006 11:03:26 von Dave Page

=20

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 27 January 2006 09:52
> To: Dave Page
> Cc: Ludek Finstrle; pgsql-odbc@postgresql.org; Tom Lane
> Subject: Re: [ODBC] Disallow premature is broken
>=20
> > > What do you think? How do we want change the behaviout before
> > > releasing new stable release? I'm not sure. There is no much time
> > > for testing new behaviour. The multistatements hasn't=20
> been reported
> > > yet by users. It seems this feature isn't widely used.
> >=20
> > In the short term though, I say just stop it crashing and=20
> let's get a
> > release out seeing as Tom is getting antsy about FC5 :-)
>=20
> Ok. I agree. (what is the word "antsy" I can't find it in vocabulary).

Nervous that it might not arrive in time.

> > Can you produce a final 08.01.0108 dev build, and I'll look to build
> > 08.01.0200 on say Tuesday/Wednesday? Does that work for you Tom?
>=20
> I'll try to create the patch for Disallow Premature today. But I'm not
> sure if I will have enough time for it. I have few time today=20
> and during
> weekend :-(

:-( Me too.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Disallow premature is broken

am 27.01.2006 16:02:11 von Tom Lane

Ludek Finstrle writes:
>> In the short term though, I say just stop it crashing and let's get a
>> release out seeing as Tom is getting antsy about FC5 :-)

> What's the next deadline Tom? I ask to know how much I'm under pressure.
> If we are too late I could sleep for a shorter time today.

No, no, working on too little sleep is a good way to mess up...

According to http://fedora.redhat.com/About/schedule/
the next deadline is test3 devel freeze on 6 February, which is
a week from Monday. So if we can get a release made by say the
middle of next week, there's plenty of time to push it into FC5.

BTW, I do have an x86_64 FC4 machine here, and will try to look at that
buffer overflow report today.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Disallow premature is broken

am 27.01.2006 16:24:05 von Ludek Finstrle

Fri, Jan 27, 2006 at 10:02:11AM -0500, Tom Lane napsal(a):
> Ludek Finstrle writes:
> >> In the short term though, I say just stop it crashing and let's get a
> >> release out seeing as Tom is getting antsy about FC5 :-)
>
> > What's the next deadline Tom? I ask to know how much I'm under pressure.
> > If we are too late I could sleep for a shorter time today.
>
> No, no, working on too little sleep is a good way to mess up...

I make exception. I want give users one development snapshot before
official release. I give less time for psqlodbc in next week ;-)

> the next deadline is test3 devel freeze on 6 February, which is

Thanks for information.

> BTW, I do have an x86_64 FC4 machine here, and will try to look at that
> buffer overflow report today.

Good news. I have problem on x86_64 CentOS with disconnecting. I'm
curios if it's only my local problem. I have no time to trace it
more now. I don't know very well gdb and next development tools for
C on unix.

The disconnecting problem is with perl code:

use DBI;

my $dbh = DBI->connect('dbi:ODBC:','username','password');
print "connect\n";
$dbh->disconnect;
print "This message doesn't show\n";
# This perl script fails with SIGSEGV.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Disallow premature is broken

am 27.01.2006 23:38:39 von Ludek Finstrle

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Fri, Jan 27, 2006 at 09:39:05AM -0000, Dave Page wrote:
> > What do you think? How do we want change the behaviout before
> > releasing new stable release? I'm not sure. There is no much time
> > for testing new behaviour. The multistatements hasn't been reported
> > yet by users. It seems this feature isn't widely used.
>
> In the short term though, I say just stop it crashing and let's get a
> release out seeing as Tom is getting antsy about FC5 :-)

Here is the patch. I'll include it into 08.01.0108 dev snapshot.
psqlodbc doesn't fall down on exception when "Disallow premature"
is checked and: SQLPrepare, SQLNumResultCols is called.
The SQLNumResultCols returns SQLSTATE HY0000 with message like
No result was returned by the query.

Please review and comment

Regards,

Luf

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="psqlodbc-disallow_premature_not_fail.diff"

diff -c psqlodbc.orig\execute.c psqlodbc\execute.c
*** psqlodbc.orig\execute.c Sun Dec 25 09:22:49 2005
--- psqlodbc\execute.c Sat Jan 28 00:19:05 2006
***************
*** 256,262 ****
return SQL_ERROR;
}
SC_set_Result(stmt, res);
! for (curres = res; !curres->num_fields; curres = curres->next)
;
SC_set_Curres(stmt, curres);
if (CC_is_in_autocommit(conn))
--- 256,262 ----
return SQL_ERROR;
}
SC_set_Result(stmt, res);
! for (curres = res; curres && !curres->num_fields; curres = curres->next)
;
SC_set_Curres(stmt, curres);
if (CC_is_in_autocommit(conn))

--mYCpIKhGyMATD0i+
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--mYCpIKhGyMATD0i+--

Re: Disallow premature is broken

am 28.01.2006 22:25:58 von Dave Page

On 27/1/06 22:38, "Ludek Finstrle" wrote:

> Fri, Jan 27, 2006 at 09:39:05AM -0000, Dave Page wrote:
>>> What do you think? How do we want change the behaviout before
>>> releasing new stable release? I'm not sure. There is no much time
>>> for testing new behaviour. The multistatements hasn't been reported
>>> yet by users. It seems this feature isn't widely used.
>>
>> In the short term though, I say just stop it crashing and let's get a
>> release out seeing as Tom is getting antsy about FC5 :-)
>
> Here is the patch. I'll include it into 08.01.0108 dev snapshot.
> psqlodbc doesn't fall down on exception when "Disallow premature"
> is checked and: SQLPrepare, SQLNumResultCols is called.
> The SQLNumResultCols returns SQLSTATE HY0000 with message like
> No result was returned by the query.
>
> Please review and comment

Looks like a perfectly fine temporary fix.

Regards, Dave.


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org