On Sat, Sep 14, 2019 at 03:51:03PM +0200, Daniel Verite wrote:
> What about DEBUG1 as the level?
> Surely we can draw a line somewhere beyond which the benefit of
> getting that information surpasses the annoyance factor that
> you're foreseeing?
DEBUG1 is even more chatty. I agree with the other
On Sat, Sep 14, 2019 at 8:13 AM Tom Lane wrote:
> The advantage of describe_collation(oid) is that we would not be
> building knowledge into the callers about which columns of pg_collation
> matter for this purpose. I'm not even convinced that the two you posit
> here are sufficient --- the encod
"Daniel Verite" writes:
> Tom Lane wrote:
>> I think that's a useful function, but it's a different function from
>> the one first proposed, which was to tell you the properties of a
>> collation you already installed (which might not be ICU, even).
>> Perhaps we should have both.
> The pre
Tom Lane wrote:
> > This output tend to reveal mistakes with tags, which is why I thought
> > to expose it as a NOTICE. It addresses the case of a user
> > who wouldn't suspect an error, so the "in-your-face" effect is
> > intentional. With the function approach, the user must be
> > proac
Tom Lane wrote:
> I think that's a useful function, but it's a different function from
> the one first proposed, which was to tell you the properties of a
> collation you already installed (which might not be ICU, even).
> Perhaps we should have both.
The pre-create use case would look l
On Fri, Sep 13, 2019 at 11:09:52AM -0400, Tom Lane wrote:
> I think that's a useful function, but it's a different function from
> the one first proposed, which was to tell you the properties of a
> collation you already installed (which might not be ICU, even).
> Perhaps we should have both.
Perh
On Fri, Sep 13, 2019 at 11:12 AM Tom Lane wrote:
> That argument presupposes (a) manual execution of the creation query,
> and (b) that the user pays close attention to the NOTICE output.
> Unfortunately, I think our past over-use of notices has trained
> people to ignore them.
Our past overuse a
"Daniel Verite" writes:
> This output tend to reveal mistakes with tags, which is why I thought
> to expose it as a NOTICE. It addresses the case of a user
> who wouldn't suspect an error, so the "in-your-face" effect is
> intentional. With the function approach, the user must be
> proactive.
Tha
Robert Haas writes:
> On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite wrote:
>> An advantage of this approach is that you may execute the
>> function before creating the collation, instead of creating the
>> collation, realizing there was something wrong in your
>> locale/lc_collate argument, dropp
On Fri, Sep 13, 2019 at 9:57 AM Daniel Verite wrote:
> An advantage of this approach is that you may execute the
> function before creating the collation, instead of creating the
> collation, realizing there was something wrong in your
> locale/lc_collate argument, dropping the collation and tryin
Michael Paquier wrote:
> Or could it make sense to provide a system function which returns a
> collation description for at least an ICU-provided one? We could make
> use of that in psql for example.
If we prefer having a function over the instant feedback effect of
the NOTICE, the funct
Michael Paquier writes:
> On Thu, Sep 12, 2019 at 03:03:43PM -0400, Tom Lane wrote:
>> The idea of having CREATE COLLATION automatically create a comment
>> is sort of interesting, although it seems pretty orthogonal to
>> normal command behavior. I wonder whether the seeming need for
>> this ind
On Thu, Sep 12, 2019 at 03:03:43PM -0400, Tom Lane wrote:
> The idea of having CREATE COLLATION automatically create a comment
> is sort of interesting, although it seems pretty orthogonal to
> normal command behavior. I wonder whether the seeming need for
> this indicates that we should add a des
Alvaro Herrera writes:
> I wonder if INFO is better than NOTICE (I think it is).
You're just waving a red flag in front of a bull, you know.
I don't especially like the idea of having this emit a NOTICE;
it's ugly and in-your-face. INFO is right out.
The idea of having CREATE COLLATION automat
On 2019-Sep-12, Daniel Verite wrote:
> Michael Paquier wrote:
>
> > On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> > > I think it would be nice to have CREATE COLLATION report this
> > > information as feedback in the form of a NOTICE message.
> > > PFA a simple patch impl
On Thu, Sep 12, 2019 at 11:30 AM Peter Geoghegan wrote:
> I wonder if it's possible to display a localized version of the
> display string in the NOTICE message? Does that work, or could it? For
> example, do you see the message in French?
BTW, I already know for sure that ICU supports localized
On Wed, Sep 11, 2019 at 7:53 AM Daniel Verite wrote:
> The 'locale' or 'lc_collate/lc_ctype' argument of an ICU collation may
> have a complicated syntax, especially with non-deterministic
> collations, and input mistakes in these names will not necessarily be
> detected as such by ICU.
That's a
Michael Paquier wrote:
> On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> > I think it would be nice to have CREATE COLLATION report this
> > information as feedback in the form of a NOTICE message.
> > PFA a simple patch implementing that.
>
> Why is that better than the
On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> I think it would be nice to have CREATE COLLATION report this
> information as feedback in the form of a NOTICE message.
> PFA a simple patch implementing that.
Why is that better than the descriptions provided with \dO[S]+ in
psql?
Hi,
The 'locale' or 'lc_collate/lc_ctype' argument of an ICU collation may
have a complicated syntax, especially with non-deterministic
collations, and input mistakes in these names will not necessarily be
detected as such by ICU.
The "display name" of a locale is a simple way to get human-reada
20 matches
Mail list logo
