John Naylor writes:
> I believe it's actually "lower than Op", and since POSTFIXOP is gone
> it doesn't seem to matter how low it is. In fact, I found that the
> lines with INDENT and UNBOUNDED now work as the lowest precedence
> declarations. Maybe that's worth something?
> Following on Peter
On Fri, Sep 18, 2020 at 4:48 PM Tom Lane wrote:
> Pushed with the discussed terminological changes and some other
> fooling about, including fixing the documentation.
Awesome. Thanks!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Pushed with the discussed terminological changes and some other
fooling about, including fixing the documentation.
regards, tom lane
Robert Haas writes:
> On Fri, Sep 18, 2020 at 2:11 PM Tom Lane wrote:
>> What I now propose is to add two output columns:
>>
>> barelabel bool (t or f, obviously)
>> baredesc text ("can be bare label" or "requires AS", possibly localized)
> That might be over-engineered in a vacuum, but it
On Fri, Sep 18, 2020 at 2:11 PM Tom Lane wrote:
> After re-reading the description of pg_get_keywords, I was reminded that
> what it outputs now is intended to provide both a machine-friendly
> description of the keyword category ("catcode") and a human-friendly
> description ("catdesc"). So we
Robert Haas writes:
> On Fri, Sep 18, 2020 at 11:29 AM Tom Lane wrote:
>> As for what to expose in pg_get_keywords, I think something like
>> "label_requires_as bool" would be immediately understandable.
>> If you really want it to be an enum sort of thing, maybe the output
>> column title could
On Fri, Sep 18, 2020 at 11:29 AM Tom Lane wrote:
> I confess to not having paid very close attention to this thread
> lately, but the last I'd noticed the terminology proposed for
> internal use was "bare column label", which I think is much better.
I agree.
> As for what to expose in
> On Sep 18, 2020, at 8:29 AM, Tom Lane wrote:
>
> So I've finished up applying 0001 and started to look at 0002
> ... and I find the terminology you've chosen to be just really
> opaque and confusing. "aliastype" being "implicit" or "explicit"
> is not going to make any sense to anyone
So I've finished up applying 0001 and started to look at 0002
... and I find the terminology you've chosen to be just really
opaque and confusing. "aliastype" being "implicit" or "explicit"
is not going to make any sense to anyone until they read the
manual, and it probably still won't make sense
Robert Haas writes:
> I'm not sure who is going to commit this work, and that person may
> have a different preference than me. However, if it's me, I'd like to
> see the removal of the existing postfix operators broken off into its
> own patch, separate from the removal of the underlying
Mark Dilger writes:
> On Sep 11, 2020, at 12:54 PM, Robert Haas wrote:
>> On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
>> wrote:
>>> Another option would be to have pg_dump take a strictness mode option. I
>>> don't think the option should have anything to do with postfix operators
>>>
> On Sep 11, 2020, at 12:54 PM, Robert Haas wrote:
>
> On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
> wrote:
>> Another option would be to have pg_dump take a strictness mode option. I
>> don't think the option should have anything to do with postfix operators
>> specifically, but be more
On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
wrote:
> Another option would be to have pg_dump take a strictness mode option. I
> don't think the option should have anything to do with postfix operators
> specifically, but be more general like --dump-incompatible-objects vs.
>
> On Sep 11, 2020, at 11:25 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>>> My inclination is to simply not change pg_dump. There is no need to break
>>> the use-case of loading the output back into the server version it came
>>> from, if we
Mark Dilger writes:
> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>> My inclination is to simply not change pg_dump. There is no need to break
>> the use-case of loading the output back into the server version it came
>> from, if we don't have to. If the output is getting loaded into a server
> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
>> wrote:
>>> Since newer pg_dump binaries can be used to dump data from older servers,
>>> and since users might then load that dump back into an older server, I
>>>
Robert Haas writes:
> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
> wrote:
>> Since newer pg_dump binaries can be used to dump data from older servers,
>> and since users might then load that dump back into an older server, I think
>> doing anything stronger than a pg_log_warning() would be
On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
wrote:
> Since newer pg_dump binaries can be used to dump data from older servers, and
> since users might then load that dump back into an older server, I think
> doing anything stronger than a pg_log_warning() would be incorrect. I did
> not find
On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
wrote:
> [v7]
Ok, I've marked it ready for committer.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Sep 1, 2020 at 10:00 PM Mark Dilger
wrote:
>
> Some changes were made on another thread [1] for the deprecation notices,
> committed recently by Tom, and I think this patch set is compatible with what
> was done there. This patch set is intended for commit against master,
> targeted
On Fri, Aug 28, 2020 at 11:00 AM Robert Haas wrote:
> On Fri, Aug 28, 2020 at 4:44 AM John Naylor
> wrote:
> > On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> > > I'm a bit inclined to kill them both off and standardize on factorial()
> > > (not numeric_fac).
> >
> > +1
>
> Here's a modified
On Fri, Aug 28, 2020 at 4:44 AM John Naylor wrote:
> On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> > I'm a bit inclined to kill them both off and standardize on factorial()
> > (not numeric_fac).
>
> +1
Here's a modified version of John's patch that also describes ! and !!
as deprecated. It
On Wed, Aug 26, 2020 at 6:57 PM Mark Dilger
wrote:
> I don't have any problem with the changes you made in your patch, but
> building on your changes I also found that the following cleanup causes no
> apparent problems:
>
> -%nonassoc UNBOUNDED /* ideally should have same
>
On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> I'm a bit inclined to kill them both off and standardize on factorial()
> (not numeric_fac).
+1
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Aug 27, 2020 at 10:04 AM Tom Lane wrote:
> Well, the !! operator itself has been "deprecated" for a long time:
>
> regression=# \do+ !!
> List of operators
>Schema | Name | Left arg type | Right arg type | Result type | Function
> |
> On Aug 27, 2020, at 7:04 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> Yeah, that looks like a good spot. I think we should also add
>> something to the documentation of the factorial operator, mentioning
>> that it will be going away. Perhaps we can advise people to write !!3
>> instead
Robert Haas writes:
> Yeah, that looks like a good spot. I think we should also add
> something to the documentation of the factorial operator, mentioning
> that it will be going away. Perhaps we can advise people to write !!3
> instead of 3! for forward-compatibility, or maybe we should instead
On Thu, Aug 27, 2020 at 7:12 AM John Naylor wrote:
> Well, for starters it'll say the obvious, but since we have a concrete
> timeframe, maybe a tag to make it more visible, like in the
> attached, compressed to avoid confusing the cfbot.
Yeah, that looks like a good spot. I think we should
On Wed, Aug 26, 2020 at 8:55 PM Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 11:57 AM Mark Dilger
> wrote:
> > I wonder if we can get more comments for or against this patch, at least in
> > principle, in the very near future, to help determine whether the
> > deprecation notices should go
On Wed, Aug 26, 2020 at 6:57 PM Mark Dilger
wrote:
>
>
>
> > On Aug 26, 2020, at 6:33 AM, John Naylor
> > wrote:
>
> > and since POSTFIXOP is gone
> > it doesn't seem to matter how low it is. In fact, I found that the
> > lines with INDENT and UNBOUNDED now work as the lowest precedence
> >
On Wed, Aug 26, 2020 at 11:57 AM Mark Dilger
wrote:
> I wonder if we can get more comments for or against this patch, at least in
> principle, in the very near future, to help determine whether the deprecation
> notices should go into v13?
Speaking of that, has somebody written a specific
On Wed, Aug 26, 2020 at 6:12 AM Mark Dilger
wrote:
>
> The construction colname AS colalias brings to mind the words "pseudonym" and
> "alias". The distinction we're trying to draw here is between implicit
> pseudoyms and explicit ones, but "alias" is shorter and simpler, so I like
> that
> On Aug 24, 2020, at 12:28 AM, John Naylor wrote:
>
> On Tue, May 19, 2020 at 5:03 AM Tom Lane wrote:
>>
>> Peter Eisentraut writes:
>>> What are the thoughts about then marking the postfix operator deprecated
>>> and eventually removing it?
>>
>> If we do this it'd require a plan. We'd
On Tue, May 19, 2020 at 5:03 AM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > What are the thoughts about then marking the postfix operator deprecated
> > and eventually removing it?
>
> If we do this it'd require a plan. We'd have to also warn about the
> feature deprecation in (at least)
On Wed, Jul 22, 2020 at 8:47 AM Mark Dilger
wrote:
>
>
>
> > On Jul 18, 2020, at 1:00 AM, John Naylor
> > wrote:
> >
> > pg_get_keywords() should probably have a column to display ability to
> > act as a bare col label. Perhaps a boolean? If so, what do you think
> > of using true/false for the
On Sat, Jul 11, 2020 at 1:14 AM Mark Dilger
wrote:
>
> > Tom and Álvaro discussed upthread:
> >
> >> Would it make sense (and possible) to have a keyword category that is
> >> not disjoint wrt. the others? Maybe that ends up being easier than
> >> a solution that ends up with six or seven
> On Jun 30, 2020, at 2:47 PM, Mark Dilger wrote:
>
>
>
>> On May 19, 2020, at 4:47 PM, Tom Lane wrote:
>>
>> I wrote:
>>> However, we do have to have a benefit to show those people whose
>>> queries we break. Hence my insistence on having a working AS fix
>>> (or some other benefit)
Peter Eisentraut writes:
> What I was hoping to get out of this was to resolve some of the weird
> precedence hacks that were blamed on postfix operators.
Yeah, I was thinking about that too, but hadn't gotten to it.
> But building on your patch, the best I could achieve was
> -%nonassoc
On 2020-05-20 01:47, Tom Lane wrote:
I wrote:
However, we do have to have a benefit to show those people whose
queries we break. Hence my insistence on having a working AS fix
(or some other benefit) before not after.
I experimented with this a bit more, and came up with the attached.
It's
On Wed, May 20, 2020 at 2:24 PM Tom Lane wrote:
> Right; I'd done the same arithmetic. Since we currently have a total
> of 450 keywords of all flavors, that means we can make either 64%
> of them or 74.6% of them be safe to use as bare column labels. While
> that's surely better than today, it
Alvaro Herrera writes:
> On 2020-May-20, Tom Lane wrote:
>> I feel like we'd be better advised to somehow
>> treat can-be-bare-col-label as an independent classification.
> Would it make sense (and possible) to have a keyword category that is
> not disjoint wrt. the others? Maybe that ends up
On 2020-May-20, Tom Lane wrote:
> I too failed to save the results of some experimentation, but I'd
> also poked at the type_func_name_keyword category, and it has a similar
> situation where only about three keywords cause problems if included
> in BareColLabel. So we could possibly get another
Mark Dilger writes:
> ... But if we made a clean distinction between the characters that are
> allowed in postfix operators vs. those allowed for infix operators, then we'd
> get to have postfix operators without the ambiguity, right?
I continue to see little point in half-baked compatibility
> On May 20, 2020, at 11:24 AM, Tom Lane wrote:
>
> Bottom line is that we can reduce the scope of the col-label problem
> this way, but we can't make it go away entirely. Is a partial solution
> to that worth a full drop of postfix operators? Possibly, but I'm not
> sure. I still feel
Robert Haas writes:
> On Tue, May 19, 2020 at 7:47 PM Tom Lane wrote:
>> However, as the patch
>> stands, only the remaining fully-unreserved keywords can be used as bare
>> column labels. I'd hoped to be able to also use col_name keywords in that
>> way (which'd make the set of legal bare
On Tue, May 19, 2020 at 7:47 PM Tom Lane wrote:
> As Robert theorized, it works to move a fairly-small number of unreserved
> keywords into a new slightly-reserved category.
It wasn't entirely a theoretical argument, since I'm pretty sure I did
spend some time experimenting with gram.y back in
I wrote:
> However, we do have to have a benefit to show those people whose
> queries we break. Hence my insistence on having a working AS fix
> (or some other benefit) before not after.
I experimented with this a bit more, and came up with the attached.
It's not a working patch, just a set of
Robert Haas writes:
> On Tue, May 19, 2020 at 2:30 PM Tom Lane wrote:
>> Anyway, the bottom-line conclusion remains the same: let's make sure
>> we know what we'd do after getting rid of postfix ops, before we do
>> that.
> Well, I don't think we really need to get too conservative here.
> ...
On Tue, May 19, 2020 at 2:30 PM Tom Lane wrote:
> Might work. My main concern would be if we have to forbid those keywords
> as column names --- for words like "year", in particular, that'd be a
> disaster. If the net effect is only that they can't be AS-less col labels,
> it won't break any
Robert Haas writes:
> On Tue, May 19, 2020 at 11:32 AM Tom Lane wrote:
>> Before we go much further on this, we should have some proof
>> that there's actually material benefit to be gained. I spent some
>> time just now trying to relax the AS restriction by ripping out
>> postfix ops, and the
On Tue, May 19, 2020 at 11:32 AM Tom Lane wrote:
> Before we go much further on this, we should have some proof
> that there's actually material benefit to be gained. I spent some
> time just now trying to relax the AS restriction by ripping out
> postfix ops, and the results were not too
Vik Fearing writes:
> I'm -1 on keeping ! around as a hard-coded postfix operator.
Before we go much further on this, we should have some proof
that there's actually material benefit to be gained. I spent some
time just now trying to relax the AS restriction by ripping out
postfix ops, and the
Greetings,
* Vik Fearing (v...@postgresfriends.org) wrote:
> On 5/19/20 4:03 AM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> What are the thoughts about then marking the postfix operator deprecated
> >> and eventually removing it?
> >
> > If we do this it'd require a plan. We'd have to
Robert Haas writes:
> The ambiguity doesn't come from the mere existence of postfix
> operators. It comes from the fact that, when we lex the input, we
> can't tell whether a particular operator that we happen to encounter
> is prefix, infix, or postfix. So hard-coding, for example, a rule that
>
On 5/19/20 4:22 PM, Robert Haas wrote:
> On Tue, May 19, 2020 at 9:51 AM Tom Lane wrote:
>> Uh ... what exactly would be the point of that? The real reason to do
>> this at all is not that we have it in for '!', but that we want to
>> drop the possibility of postfix operators from the grammar
On Tue, May 19, 2020 at 9:51 AM Tom Lane wrote:
> Uh ... what exactly would be the point of that? The real reason to do
> this at all is not that we have it in for '!', but that we want to
> drop the possibility of postfix operators from the grammar altogether,
> which will remove a boatload of
Robert Haas writes:
> I think it's generally a good idea, though perhaps we should consider
> continuing to allow '!' as a postfix operator and just removing
> support for any other.
Uh ... what exactly would be the point of that? The real reason to do
this at all is not that we have it in for
>
> I won't lose a lot of sleep if we decide to rip out '!' as well, but I
> don't think that continuing to support it would cost us much.
>
+1 for keeping ! and nuking the rest, if possible.
Regards,
Ken
út 19. 5. 2020 v 14:27 odesílatel Robert Haas
napsal:
> On Mon, May 18, 2020 at 10:42 AM Peter Eisentraut
> wrote:
> > What are the thoughts about then marking the postfix operator deprecated
> > and eventually removing it?
>
> I wrote a little bit about this last year:
>
>
>
On Mon, May 18, 2020 at 10:42 AM Peter Eisentraut
wrote:
> What are the thoughts about then marking the postfix operator deprecated
> and eventually removing it?
I wrote a little bit about this last year:
http://postgr.es/m/CA+TgmoarLfSQcLCh7jx0737SZ28qwbuy+rUWT6rSHAO=b-6...@mail.gmail.com
I
On 5/19/20 4:03 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> What are the thoughts about then marking the postfix operator deprecated
>> and eventually removing it?
>
> If we do this it'd require a plan. We'd have to also warn about the
> feature deprecation in (at least) the CREATE
On Mon, May 18, 2020 at 10:03:13PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > What are the thoughts about then marking the postfix operator deprecated
> > and eventually removing it?
>
> If we do this it'd require a plan. We'd have to also warn about the
> feature deprecation in (at
Peter Eisentraut writes:
> What are the thoughts about then marking the postfix operator deprecated
> and eventually removing it?
If we do this it'd require a plan. We'd have to also warn about the
feature deprecation in (at least) the CREATE OPERATOR man page, and
we'd have to decide how many
On Mon, May 18, 2020 at 05:02:34PM +0200, Vik Fearing wrote:
> On 5/18/20 4:42 PM, Peter Eisentraut wrote:
> > There have been occasional discussions about deprecating or phasing out
> > postfix operators, to make various things easier in the parser.
> >
> > The first step would in any case be to
On 5/18/20 4:42 PM, Peter Eisentraut wrote:
> There have been occasional discussions about deprecating or phasing out
> postfix operators, to make various things easier in the parser.
>
> The first step would in any case be to provide alternatives for the
> existing postfix operators. There is
65 matches
Mail list logo
