On Tuesday 18 December 2007 18:30:22 Tom Lane wrote:
Arguably, pg_dump from an older version should make sure that the auto
rules should NOT get created, else it is failing to preserve an older
view's behavior.
We extend properties of objects all the time. That is why we make new
releases.
On Tuesday 27 January 2009 14:07:26 Peter Eisentraut wrote:
On Tuesday 18 December 2007 18:30:22 Tom Lane wrote:
Arguably, pg_dump from an older version should make sure that the auto
rules should NOT get created, else it is failing to preserve an older
view's behavior.
We extend
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 18 December 2007 18:30:22 Tom Lane wrote:
Arguably, pg_dump from an older version should make sure that the auto
rules should NOT get created, else it is failing to preserve an older
view's behavior.
We extend properties of objects all the
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 18 December 2007 18:30:22 Tom Lane wrote:
Arguably, pg_dump from an older version should make sure that the auto
rules should NOT get created, else it is failing to preserve an older
view's behavior.
We extend
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
When dealing with binary, the Oid the client sends may match what the
server thinks but the data is wrong (client sent binary formatted data
of the wrong type). Thus, the only real check we saw was on the data
length (which is rolling
PQlookupOid(PGconn *conn, char **type_names, Oid *oids, int count);
We are backing away from this (not such a great idea). We are actually
working hard at removing Oid dependencies from our PGparam idea. We
think it is more generic to make the server allow InvalidOid for
composites and
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much.
Other than the ability to detect errors before the code goes off
