Tom Lane writes:
> Actually, after I got done hacking the temp-schema case, I realized that
> preventing temp tables from becoming extension members isn't so ugly as
> I first thought; in fact, it's pretty much a one-liner, and much cleaner
> than hacking ON COMMIT DROP. PFA a patch that fixes bo
Bill MacArthur writes:
> Perhaps this issue has been resolved in higher sub-versions or in 9.1?
No, seems to be just the same in HEAD :-(
> In summary, the issue revolves around the data type of a column being
> changed, but the data type in a dependent rule on another table does not.
> Does t
Hello,
Perhaps this issue has been resolved in higher sub-versions or in 9.1?
In summary, the issue revolves around the data type of a column being changed,
but the data type in a dependent rule on another table does not. Does the data
type have to be embedded in the rule?
Sorry if the issue ha
I wrote:
> Dimitri Fontaine writes:
>> Could we force temp tables created in an extension script to be ON
>> COMMIT DROP so that CurrentExtensionObject is still set and your patch
>> kicks in, preventing the DROP cascading?
> Huh, yeah, that might work. It's ugly but at least the ugliness is
> l
Hello,
Perhaps this issue has been resolved in higher sub-versions or in 9.1?
In summary, the issue revolves around the data type of a column being changed,
but the data type in a dependent rule on another table does not. Does the data
type have to be embedded in the rule?
Sorry if the issue ha
wrote:
> My postgresql does not start and giving me this error:
>
> Could not connect to server: Connection refused (0x274D/10061)
> Is the server running on host *127.0.0.1* and accepting TCP/IP
> connections on port 5432?
That message looks like it is coming from some client software on
Dimitri Fontaine writes:
> Tom Lane writes:
>> 1. If you forget to drop the temp table before ending the script,
>> then when the session ends and the temp table is forcibly dropped,
>> the whole extension goes away (following the rule that a forced drop
>> of an extension member makes the whole
On Wed, Mar 7, 2012 at 2:49 PM, Merlin Moncure wrote:
> On a practical level, the error blocks nothing -- you can bypass it
> trivially. It's just an annoyance that prevents things that users
> would like to be able to do with table row types. So I'd argue to
> remove the check, although I can
Tom Lane writes:
> 1. If you forget to drop the temp table before ending the script,
> then when the session ends and the temp table is forcibly dropped,
> the whole extension goes away (following the rule that a forced drop
> of an extension member makes the whole extension go away). This is
> m
