or so, and the
EST/EDT stuff on the Olsen tz database 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
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 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
ecided that they
>can't use 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, Sen
OID to match the format of the
binary parameter it sends, the server can unambiguously decode the data
(and cast the type, if need be).
I would go as far as to suggest that postgres should not accept binary
parameters with an "unknown" OID - it's dangerous, unreliable and serves
no pur
sed to the function hasn't been
>assembled 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/
>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.
--
An
se the
"unknown" oid, bad things will happen (sooner or later).
While this is strictly true 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,
(type
>error caught; 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
ht
>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 deco
>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 tex
parameters - the server
will see a blob of binary data and have no way 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-ha
re modern implementation.
Psycopg was (is?) also using Protocol 2. 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 exer
b, but it's never
going 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 Devel
>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
by the offending developer... 8-), and this gave me just enough space
to VACUUM FULL one 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
es for OS X?
Ah - after some more 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
>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
On 26/05/2009, at 10:25 AM, Tom Lane wrote:
Andrew McNamara 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 of
those
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 m
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 p
21 matches
Mail list logo
