has been a source of annoyance
for a very long time, eg:
http://thread.gmane.org/gmane.comp.time.tz/2262
Quite likely this change will break stuff, but my feeling is more people
will be cheering than screaming.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au
it in production, and it's proven to be
fast and stable.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew McNamara andr...@object-craft.com.au writes:
The solution is to write the query in an unambiguous way:
SELECT $1::date + 1;
You are missing the point: this is not about what types the SQL execution
sees. It is about making sure the correct recv function is applied to
the binary
as far as to suggest that postgres should not accept binary
parameters with an unknown OID - it's dangerous, unreliable and serves
no purpose.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
postgresql.
It's very, very difficult (but not impossible) to support both python 2
and 3 simultaneously, particularly if you have non-trivial C extension
code. Even the python gods will admit that it's still early days.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au
That's just a matter of prioritizing the issues. Put the big ones at
the top, the trivia at the bottom, [...]
I'd like to see a requirement for the use of PQexecParams() over PQexec() -
even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
--
Andrew McNamara, Senior
from parts somewhere along the way.
The point is that if the driver is doing the right thing, the user of
the driver at least has to choice to do things safely.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql
to know what it represents.
I presume DBD::Pg is using text parameters, rather than binary.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote:
I can't see how this would work with binary query parameters - the server
will see a blob of binary data and have no way to know what it represents.
Unknown is unknown, whether in binary or text format. As far as I know,
PostgreSQL never
On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote:
The problem is deeper than that - when query parameters use the binary
option, the server has no way to decode the binary parameter without an
appropriate type OID.
Postgres does not attempt to decode anything (text or binary format
; better).
This is the crux of the matter: the type input functions are universally
more forgiving since, by their nature, text formats are designed for us
fuzzy humans, and users of adapters have come to expect this.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au
of both binary and text parameters, text
parameters have enough redundancy built into the format that it's rarely
a problem. Users have come to expect this leniency.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql
to delight or surprise. A PostGreSQL blessed adapter really should
provide access to all the features in libpq, and I'm not sure this is
directly compatible with DBAPI. Instead, the DBAPI-compliance should be
layered on top.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object
. I felt that the way forward was
to switch to the Protocol 3 API features, in particular, parameterised
queries, and none of the existing Python adapters had done that (I got
the impression while writing my module that nobody was exercising the
new features).
--
Andrew McNamara, Senior Developer
table at a time.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Well, Andrew McNamara just posted today:
http://archives.postgresql.org/message-id/20090916063341.0735c5ac...@longblack.object-craft.com.au
Had VACUUM FULL not been available, though, I'm pretty sure he would've
come up with something else instead.
Indeed I would have. And it was our own
The packager team is planning minor releases of 7.4.X to 8.4.X. The
packaging of the releases will be done on September 3-4, with release
due on September 9 (late to avoid a US holiday on September 7).
Is this likely to include a 64 bit build in the fat binaries for OS X?
--
Andrew McNamara
googling, I think I can answer my own question:
http://www.postgresqlformac.com/news/
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 26/05/2009, at 5:41 AM, Tom Lane wrote:
The only place I can find where an oversize time value behaves in a
seriously bogus fashion is in time_out, or more specifically
EncodeTimeOnly(): it fails to initialize its output string at all.
So you could easily get garbage text output, though in
On 26/05/2009, at 10:25 AM, Tom Lane wrote:
Andrew McNamara andr...@object-craft.com.au writes:
Are there any other cases where the binary receive functions are
missing sanity checks?
Possibly --- you want to go looking?
Uh. I'd be lying if I said I wanted to - I got enough of a taste
When submitting a query via the V3 binary protocol (PQexecParams,
paramFormats[n]=1), it appears the PostgreSQL server performs no range
checking on the passed values. Passing values greater than 24 hours
results in unpredictable results (dumps that cannot be restored,
strange output when
21 matches
Mail list logo
