Re: Temporary tables under hot standby

On Fri, Jun 08, 2012 at 01:26:20PM -0400, Robert Haas wrote:
> On Sun, Apr 29, 2012 at 4:02 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > On Tue, Apr 24, 2012 at 11:55:15PM -0400, Noah Misch wrote:
> >> Concerning everyone's favorite topic, how to name the new type of table, I
> >> liked Tom's proposal[1] to make CREATE TEMP TABLE retain current behavior and
> >> have CREATE GLOBAL TEMP TABLE and/or CREATE LOCAL TEMP TABLE request the new
> >> SQL-standard variety. ?(I'd vote for using CREATE GLOBAL and retaining CREATE
> >> LOCAL for future expansion.) ?As he mentions, to get there, we'd ideally start
> >> by producing a warning instead of silently accepting GLOBAL as a noise word.
> >> Should we put such a warning into 9.2?
> >
> > Here is the change I'd make.
>
> This is listed on the open items list.
>
> I haven't ever heard anyone propose to redefine CREATE LOCAL TEMP
> TABLE to mean anything different than CREATE TEMP TABLE, so I'm
> disinclined to warn about that.

From a documentation perspective, it will be awkward to explain (or decline to
explain) that both GLOBAL TEMPORARY and LOCAL TEMPORARY are standard syntaxes
with non-standard behavior, only one of which emits a warning. That unduly
telegraphs a prediction about which one will change first/ever. Maybe that's
nonetheless the right pragmatic answer.

> I would be more open to warning people about CREATE GLOBAL TEMP TABLE
> - frankly, it's pretty wonky that we allow that but treat GLOBAL as a
> noise word in this first place. But I'm a little disinclined to have
> the message speculate about what might happen in future versions of
> PostgreSQL. Such predictions don't have a very good track record of
> being accurate.

I feel the predictions in question ("This may specify different semantics in
future versions of PostgreSQL." and "This usage is deprecated and may specify
standard-compliant behavior in the future.") were broad enough to mitigate
this concern. If we ever do change the interpretation of this syntax, to what
could it be other than the standard behavior? We're not likely to introduce a
different but still-nonstandard behavior for this standard syntax.

I wrote the verbiage that way for the benefit of users encountering the new
warning. They might reasonably ask, "Why did the PostgreSQL developers create
this work for me?" No objection to removing the errhint, but I think the
documentation wording should stay.

Concerning whether to make this a WARNING or an ERROR, does anyone still
object to WARNING?

Thanks,
nm