Tom Lane wrote:
> Peter Eisentraut 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 properti
Peter Eisentraut 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 time. T
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
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.
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
On Dec 18, 2007 11:30 AM, Tom Lane <[EMAIL PROTECTED]> 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 rea
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 the dice)
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
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 into
the weed
>> 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 ar
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. The backend apparently knows the Oid of a
composite or array elemtype, so if the sender chooses to send InvalidOid
why should
11 matches
Mail list logo
