* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > That's a good point, we might be doing things wrong in other places in
> > the code by using FirstNormalObjectId on pre-8.1 servers.
>
> > What I suggest then is an independent patch which uses a different
> > variable than FirstN
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > That's a good point, we might be doing things wrong in other places in
> > the code by using FirstNormalObjectId on pre-8.1 servers.
>
> > What I suggest then is an independent patch which uses a different
> > variable than
Stephen Frost writes:
> That's a good point, we might be doing things wrong in other places in
> the code by using FirstNormalObjectId on pre-8.1 servers.
> What I suggest then is an independent patch which uses a different
> variable than FirstNormalObjectId and sets it correctly based on the
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> (Actually, the most likely way in which this would break things is if
> >> it started causing built-in casts to get dumped ... have you checked?)
>
> > So, this is fun. Apparently casts
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Ok, thinking a bit more on this and testing, it looks like we record the
> > initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3.
> > Therefore, we could use that as the gating factor for getFuncs() instead
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> (Actually, the most likely way in which this would break things is if
>> it started causing built-in casts to get dumped ... have you checked?)
> So, this is fun. Apparently casts had OIDs > FirstNormalObjectId back
> in 8.0 and e
Stephen Frost writes:
> Ok, thinking a bit more on this and testing, it looks like we record the
> initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3.
> Therefore, we could use that as the gating factor for getFuncs() instead
> of FirstNormalObjectId and then I can also modify g
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
> >> dumped. Although maybe the assumpt
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
> >> dumped. Although maybe the a
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I have a vague feeling that the code for dumping casts and/or transforms
>> may have some assumptions that the underlying function is also being
>> dumped. Although maybe the assumption was really only what's fixed here,
>> ie that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > As pointed out by Peter E, this also impacts CASTs. Attached is a patch
> > which addresses both by simply also pulling any functions which are
> > referenced from pg_cast or pg_transform when they have OIDs at or after
> > FirstN
Stephen Frost writes:
> As pointed out by Peter E, this also impacts CASTs. Attached is a patch
> which addresses both by simply also pulling any functions which are
> referenced from pg_cast or pg_transform when they have OIDs at or after
> FirstNormalObjectId. I also modified dumpCast() and du
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> While testing pg_dump, I discovered that there seems to be an issue when
> it comes to TRANSFORMs.
[...]
As pointed out by Peter E, this also impacts CASTs. Attached is a patch
which addresses both by simply also pulling any functions which are
On 5/5/16 8:33 AM, Stephen Frost wrote:
I strongly disagree with the idea that this is only an issue with the
testing system. What if we add functions in the future that are
created by initdb and *are* useful for transforms? What about casts?
There are a lot of functions in pg_catalog that a us
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/4/16 11:23 PM, Tom Lane wrote:
> >Actually, I believe it will be dumped. selectDumpableCast believes it
> >should dump casts with OID >= FirstNormalObjectId. That's a kluge no
> >doubt, but reasonably effective; looks like we've
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 5/4/16 2:39 PM, Stephen Frost wrote:
> >> These checks are looking for the functions used by the transform in the
> >> list of functions that pg_dump has loaded, but in 9.5, we don't load any
> >> of the function in pg_catalo
On 5/4/16 11:23 PM, Tom Lane wrote:
Actually, I believe it will be dumped. selectDumpableCast believes it
should dump casts with OID >= FirstNormalObjectId. That's a kluge no
doubt, but reasonably effective; looks like we've been doing that since
9.0.
pg_dump appears not to have a special-case
Peter Eisentraut writes:
> On 5/4/16 2:39 PM, Stephen Frost wrote:
>> These checks are looking for the functions used by the transform in the
>> list of functions that pg_dump has loaded, but in 9.5, we don't load any
>> of the function in pg_catalog, and even with my patches, we only dump
>> the
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 5/4/16 2:39 PM, Stephen Frost wrote:
> >These checks are looking for the functions used by the transform in the
> >list of functions that pg_dump has loaded, but in 9.5, we don't load any
> >of the function in pg_catalog, and even wi
On 5/4/16 2:39 PM, Stephen Frost wrote:
These checks are looking for the functions used by the transform in the
list of functions that pg_dump has loaded, but in 9.5, we don't load any
of the function in pg_catalog, and even with my patches, we only dump
the functions in pg_catalog that have an A
Greetings all,
While testing pg_dump, I discovered that there seems to be an issue when
it comes to TRANSFORMs. I'll be the first to admit that I'm not
terribly familiar with transforms, but I do know that if you create one
using functions from pg_catalog (as our regression tests do), the CREATE
21 matches
Mail list logo
