Tom,
> > That sounds good if it works. However ... will an add_missing_from view
> > work if add_missing_from is off in the session where the query is
> > executed?
>
> Yes, you only need to get it past the parser during CREATE VIEW.
Then the proposal sounds like a good solution to me. It woul
Josh Berkus writes:
> That sounds good if it works. However ... will an add_missing_from view work
> if add_missing_from is off in the session where the query is executed?
Yes, you only need to get it past the parser during CREATE VIEW.
regards, tom lane
---
Andrew,
> My suggestion was to set add_missing_from _in the output of pg_dump_ (or
> pg_restore) so that affected views would restore correctly. This would
> affect only the session in which the dump was restored. The changes that
> were already suggested (and since implemented, iiuc) would then m
On 2005-10-30, Robert Treat <[EMAIL PROTECTED]> wrote:
> Actually I rather liked your solution, except that it probably doesn't do
> enough to get people off that setting as others want. Ie. I generally run
> with that setting on, but I certainly don't make views/rules/etc.. that rely
> on that
On Wednesday 26 October 2005 15:33, Andrew - Supernews wrote:
> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew - Supernews <[EMAIL PROTECTED]> writes:
> >> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> >>> Pretending it's the user's mistake isn't
> >>> an answer that fits down
I wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
>>> What I suggest we do about this is change addImplicitRTE() to set
>>> inFromCl true for implicitly added RTEs, so that the view rule will
>>> later be dumped as if the query had been written
On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Pretending it's the user's mistake isn't
>>> an answer that fits down my craw very well...
>
>> I'm not claiming it's the user's mistake. My
On Wed, Oct 26, 2005 at 11:41:56AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Should we allow CREATE VIEW to run with "add_missing_from = true"
> > until we fix CREATE VIEW to handle this cleanly?
>
> No. Not only is that horridly ugly, it doesn't fix the problem,
> because CREATE VIEW i
Tom,
> After sleeping on it, I feel that we should probably just fix the code
> (to make the problem go away going forward) and document the possible
> need to turn on add_missing_from to load old dump files as an
> incompatibility. We've had worse ones.
I'll agree with you here, for (1) reason:
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Pretending it's the user's mistake isn't
>> an answer that fits down my craw very well...
> I'm not claiming it's the user's mistake. My point is that if the user
> did in fact remove add_missing
Bruce Momjian writes:
> Should we allow CREATE VIEW to run with "add_missing_from = true" until
> we fix CREATE VIEW to handle this cleanly?
No. Not only is that horridly ugly, it doesn't fix the problem, because
CREATE VIEW is just one case (see also CREATE RULE). If we were to
defeat add_miss
Should we allow CREATE VIEW to run with "add_missing_from = true" until
we fix CREATE VIEW to handle this cleanly? We emit a warning when we
add a missing FROM too, as I remember.
---
Andrew - Supernews wrote:
> On 2005-10-
On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Uh, no ... the global setting of add_missing_from does *not* tell you
>>> anything about whether there exist views in the database that were
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Uh, no ... the global setting of add_missing_from does *not* tell you
>> anything about whether there exist views in the database that were
>> created under a different setting.
> I realize that;
On 2005-10-26, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> Wild idea: how about having pg_dump include SET add_missing_from = true;
>> in the dump file if, and only if, it is set that way in the server?
>
> Uh, no ... the global setting of add_missing_fro
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Wild idea: how about having pg_dump include SET add_missing_from = true;
> in the dump file if, and only if, it is set that way in the server?
Uh, no ... the global setting of add_missing_from does *not* tell you
anything about whether there exist v
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
>> What I suggest we do about this is change addImplicitRTE() to set
>> inFromCl true for implicitly added RTEs, so that the view rule will
>> later be dumped as if the query had been written per spec.
> S
2. Revert the change to make add_missing_from default as false, and
wait a few more releases before making it default.
+1
No skin off our nose. What do we care if the default changes in a few
releases time - however there are probably many end-users who will see
problems upgrading...
Chris
On 2005-10-25, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-25 at 17:43 -0400, Tom Lane wrote:
>
>> 1. Tell people they may have to set add_missing_from = true to reload
>> a dump that contains such views.
>>
>> 2. Revert the change to make add_missing_from default as false, and
>> wai
On Tue, 2005-10-25 at 17:43 -0400, Tom Lane wrote:
> 1. Tell people they may have to set add_missing_from = true to reload
> a dump that contains such views.
>
> 2. Revert the change to make add_missing_from default as false, and
> wait a few more releases before making it default.
>
> Comments?
On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
> What I suggest we do about this is change addImplicitRTE() to set
> inFromCl true for implicitly added RTEs, so that the view rule will
> later be dumped as if the query had been written per spec.
Sounds reasonable. I wonder if this should be ba
21 matches
Mail list logo
