On Thu, Nov 2, 2023 at 11:08:53AM -0400, Bruce Momjian wrote:
> On Thu, Nov 2, 2023 at 09:58:54AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I found a cleaner improvement, attached.
> >
> > OK by me. Maybe that doesn't make the point strongly enough,
> > but we can hope it's
On Thu, Nov 2, 2023 at 09:58:54AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I found a cleaner improvement, attached.
>
> OK by me. Maybe that doesn't make the point strongly enough,
> but we can hope it's enough.
Agreed. I thought last night about the sentence and realized when we
Bruce Momjian writes:
> I found a cleaner improvement, attached.
OK by me. Maybe that doesn't make the point strongly enough,
but we can hope it's enough.
regards, tom lane
On Wed, Nov 1, 2023 at 07:34:59PM -0400, Bruce Momjian wrote:
> On Wed, Nov 1, 2023 at 07:12:48PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
> > >> But it *is* permissible, unless we add code to reject it during
> > >> SET as
On Wed, Nov 1, 2023 at 07:12:48PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
> >> But it *is* permissible, unless we add code to reject it during
> >> SET as Bruce mentioned. Which seems fairly pointless to me. It's not
> >>
Bruce Momjian writes:
> On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
>> But it *is* permissible, unless we add code to reject it during
>> SET as Bruce mentioned. Which seems fairly pointless to me. It's not
>> like there is anything unclear about the CREATE TABLE error message.
>
On Wed, Nov 1, 2023 at 06:32:37PM -0400, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Wednesday, November 1, 2023, Bruce Momjian wrote:
> >> Did you want an error from the SET command?
>
> > That would probably be a decent addition but the request was for us to add
> > “it is not
"David G. Johnston" writes:
> On Wednesday, November 1, 2023, Bruce Momjian wrote:
>> Did you want an error from the SET command?
> That would probably be a decent addition but the request was for us to add
> “it is not permissible to specify the pg_global tablespace for either
>
On Wednesday, November 1, 2023, Bruce Momjian wrote:
> On Tue, Nov 10, 2020 at 08:28:08AM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/13/bug-reporting.html
> > Description:
> >
> >
On Tue, Nov 10, 2020 at 08:28:08AM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/13/bug-reporting.html
> Description:
>
> Tablespace 'pg_global' is one of the two auto-generated tablespace by
>
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/13/bug-reporting.html
Description:
Tablespace 'pg_global' is one of the two auto-generated tablespace by
initdb, and 'pg_global' should not be used as the default_tablespace, since
it is
11 matches
Mail list logo