WITH clause in CREATE STATISTICS

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

Here's a patch to implement that. I verified that if I change
qualified_name to qualified_name_list, bison does not complain about
conflicts, so this new syntax should support extension to multiple
relations without a problem.

Yeah, WITH is fully reserved, so as long as the clause looks like
WITH ( stuff... ) you're pretty much gonna be able to drop it
wherever you want.

Discuss.

+1 for WITH at the end; the existing syntax looks weird to me too.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 04/21/2017 12:13 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

Here's a patch to implement that. I verified that if I change
qualified_name to qualified_name_list, bison does not complain about
conflicts, so this new syntax should support extension to multiple
relations without a problem.

Yeah, WITH is fully reserved, so as long as the clause looks like
WITH ( stuff... ) you're pretty much gonna be able to drop it
wherever you want.

Discuss.

+1 for WITH at the end; the existing syntax looks weird to me too.

-1 from me

I like the current syntax more, and WHERE ... WITH seems a bit weird to
me. But more importantly, one thing Dean probably considered when
proposing the current syntax was that we may add support for partial
statistics, pretty much like partial indexes. And we don't allow WITH at
the end (after WHERE) for indexes:

test=# create index on t (a) where a < 100 with (fillfactor=10);
ERROR: syntax error at or near "with"
LINE 1: create index on t (a) where a < 100 with (fillfactor=10);
^
test=# create index on t (a) with (fillfactor=10) where a < 100;

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Moin,

On Thu, April 20, 2017 8:21 pm, Tomas Vondra wrote:

On 04/21/2017 12:13 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

Here's a patch to implement that. I verified that if I change
qualified_name to qualified_name_list, bison does not complain about
conflicts, so this new syntax should support extension to multiple
relations without a problem.

Yeah, WITH is fully reserved, so as long as the clause looks like
WITH ( stuff... ) you're pretty much gonna be able to drop it
wherever you want.

Discuss.

+1 for WITH at the end; the existing syntax looks weird to me too.

-1 from me

I like the current syntax more, and WHERE ... WITH seems a bit weird to
me. But more importantly, one thing Dean probably considered when
proposing the current syntax was that we may add support for partial
statistics, pretty much like partial indexes. And we don't allow WITH at
the end (after WHERE) for indexes:

test=# create index on t (a) where a < 100 with (fillfactor=10);
ERROR: syntax error at or near "with"
LINE 1: create index on t (a) where a < 100 with (fillfactor=10);
^
test=# create index on t (a) with (fillfactor=10) where a < 100;

While I'm not sure about where to put the WITH, so to speak, I do favour
consistency.

So I'm inclinded to keep the syntax like for the "create index".

More importantly however, I'd rather see the syntax on the "ON (column)
FROM relname" to be changed to match the existing examples. (Already wrote
this to Simon, not sure if my email made it to the list)

So instead:

CREATE STATISTICS stats_name ON (columns) FROM relname

I'd rather see:

CREATE STATISTICS stats_name ON table(col);

as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
could also be extended to both more columns, expressions or other tables
like so:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b);

and even:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b) WITH (options)
WHERE t2.a > 4;

This looks easy to remember, since it compares to:

CREATE INDEX idx_name ON t2(a,b) WITH (options) WHERE t2.a > 4;

Or am I'm missing something?

Regards,

Tels

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 21 April 2017 at 22:30, Tels <nospam-pg-abuse@bloodgate.com> wrote:

I'd rather see:

CREATE STATISTICS stats_name ON table(col);

as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
could also be extended to both more columns, expressions or other tables
like so:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b);

and even:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b) WITH (options)
WHERE t2.a > 4;

How would you express a join condition with that syntax?

This looks easy to remember, since it compares to:

CREATE INDEX idx_name ON t2(a,b) WITH (options) WHERE t2.a > 4;

Or am I'm missing something?

Sadly yes, you are, and it's not the first time.

I seem to remember mentioning this to you already in [1]/messages/by-id/CAKJS1f9HMeT+7adicEaU8heOMpOB5pKkCVYZLiEZje3DVutVPw@mail.gmail.com.

Please, can you read over [2]/messages/by-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=VbJ78VQFA@mail.gmail.com, it mentions exactly what you're
proposing and why it's not any good.

[1]: /messages/by-id/CAKJS1f9HMeT+7adicEaU8heOMpOB5pKkCVYZLiEZje3DVutVPw@mail.gmail.com
[2]: /messages/by-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=VbJ78VQFA@mail.gmail.com

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Moin,

On Fri, April 21, 2017 7:04 am, David Rowley wrote:

On 21 April 2017 at 22:30, Tels <nospam-pg-abuse@bloodgate.com> wrote:

I'd rather see:

CREATE STATISTICS stats_name ON table(col);

as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
could also be extended to both more columns, expressions or other tables
like so:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b);

and even:

CREATE STATISTICS stats ON t1(col1, col2 / 2), t2 (a,b) WITH (options)
WHERE t2.a > 4;

How would you express a join condition with that syntax?

This looks easy to remember, since it compares to:

CREATE INDEX idx_name ON t2(a,b) WITH (options) WHERE t2.a > 4;

Or am I'm missing something?

Sadly yes, you are, and it's not the first time.

I seem to remember mentioning this to you already in [1].

Please, can you read over [2], it mentions exactly what you're
proposing and why it's not any good.

[1]
/messages/by-id/CAKJS1f9HMeT+7adicEaU8heOMpOB5pKkCVYZLiEZje3DVutVPw@mail.gmail.com
[2]
/messages/by-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=VbJ78VQFA@mail.gmail.com

Ah, ok, thank you, somehow I missed your answer the first time. So, just
ignore me :)

Best wishes,

Tels

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 21 April 2017 at 01:21, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:

On 04/21/2017 12:13 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

+1 for WITH at the end; the existing syntax looks weird to me too.

-1 from me

Yeah, I'm still marginally in favour of the current syntax because
it's a bit more consistent with the CREATE VIEW syntax which puts the
WITH (options) clause before the query, and assuming that multi-table
and partial statistics support do get added in the future, the thing
that the statistics get created on is going to look more like a query.

OTOH, a few people have now commented that the syntax looks weird, and
not just because of the placement of the WITH clause. I don't have any
better ideas, but it's not too late to change if anyone else does...

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 21 April 2017 at 01:21, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:

On 04/21/2017 12:13 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

Here's a patch to implement that. I verified that if I change
qualified_name to qualified_name_list, bison does not complain about
conflicts, so this new syntax should support extension to multiple
relations without a problem.

Yeah, WITH is fully reserved, so as long as the clause looks like
WITH ( stuff... ) you're pretty much gonna be able to drop it
wherever you want.

Discuss.

+1 for WITH at the end; the existing syntax looks weird to me too.

-1 from me

I like the current syntax more, and WHERE ... WITH seems a bit weird to me.
But more importantly, one thing Dean probably considered when proposing the
current syntax was that we may add support for partial statistics, pretty
much like partial indexes. And we don't allow WITH at the end (after WHERE)
for indexes:

test=# create index on t (a) where a < 100 with (fillfactor=10);
ERROR: syntax error at or near "with"
LINE 1: create index on t (a) where a < 100 with (fillfactor=10);
^
test=# create index on t (a) with (fillfactor=10) where a < 100;

OK, didn't know about WHERE clause; makes sense.

Currently WITH is supported in two places, which feels definitely
wrong. The WITH clause is used elsewhere to provide optional
parameters, and if there are none present it is optional.

OK, so lets try...

1.
No keyword at all, just list of statistics we store (i.e. just lose the WITH)
CREATE STATISTICS s1 (dependencies, ndistinct) ON (a, b) FROM t1 WHERE
partial-stuff;

and if there are options, use the WITH for the optional parameters like this
CREATE STATISTICS s1 (dependencies, ndistinct) WITH (options) ON (a,
b) FROM t1 WHERE partial-stuff;

2.
USING keyword, no brackets
CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;

and if there are options, use the WITH for the optional parameters like this
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON
(a, b) FROM t1 WHERE partial-stuff;

I think I like (2)

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2017-04-22 11:30 GMT+02:00 Simon Riggs <simon@2ndquadrant.com>:

On 21 April 2017 at 01:21, Tomas Vondra <tomas.vondra@2ndquadrant.com>
wrote:

On 04/21/2017 12:13 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Simon just pointed out that having the WITH clause appear in the middle
of the CREATE STATISTICS command looks odd; apparently somebody else
already complained on list about the same. Other commands put the WITH
clause at the end, so perhaps we should do likewise in the new command.

Here's a patch to implement that. I verified that if I change
qualified_name to qualified_name_list, bison does not complain about
conflicts, so this new syntax should support extension to multiple
relations without a problem.

Yeah, WITH is fully reserved, so as long as the clause looks like
WITH ( stuff... ) you're pretty much gonna be able to drop it
wherever you want.

Discuss.

+1 for WITH at the end; the existing syntax looks weird to me too.

-1 from me

I like the current syntax more, and WHERE ... WITH seems a bit weird to

me.

But more importantly, one thing Dean probably considered when proposing

the

current syntax was that we may add support for partial statistics, pretty
much like partial indexes. And we don't allow WITH at the end (after

WHERE)

for indexes:

test=# create index on t (a) where a < 100 with (fillfactor=10);
ERROR: syntax error at or near "with"
LINE 1: create index on t (a) where a < 100 with (fillfactor=10);
^
test=# create index on t (a) with (fillfactor=10) where a < 100;

OK, didn't know about WHERE clause; makes sense.

Currently WITH is supported in two places, which feels definitely
wrong. The WITH clause is used elsewhere to provide optional
parameters, and if there are none present it is optional.

OK, so lets try...

1.
No keyword at all, just list of statistics we store (i.e. just lose the
WITH)
CREATE STATISTICS s1 (dependencies, ndistinct) ON (a, b) FROM t1 WHERE
partial-stuff;

and if there are options, use the WITH for the optional parameters like
this
CREATE STATISTICS s1 (dependencies, ndistinct) WITH (options) ON (a,
b) FROM t1 WHERE partial-stuff;

2.
USING keyword, no brackets
CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;

and if there are options, use the WITH for the optional parameters like
this
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON
(a, b) FROM t1 WHERE partial-stuff;

I think I like (2)

+1

Regards

Pavel

On 22 April 2017 at 21:30, Simon Riggs <simon@2ndquadrant.com> wrote:

CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;

+1

Seems much more CREATE INDEX like, and that's pretty good given that
most of the complaints so far were about it bearing enough resemblance
to CREATE INDEX

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Simon Riggs wrote:

2.
USING keyword, no brackets
CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;

and if there are options, use the WITH for the optional parameters like this
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON
(a, b) FROM t1 WHERE partial-stuff;

I think I like (2)

OK, sounds sensible.

Note that the USING list is also optional -- if you don't specify it, we
default to creating all stat types. Also note that we currently don't
have any option other than stat types, so the WITH would always be empty
-- in other words we should remove it until we implement some option.

(I can readily see two possible options to implement for pg11, so the
omission of the WITH clause would be temporary:
1. sample size to use instead of the per-column values
2. whether to forcibly collect stats for all column for this stat
object even if the column has gotten a SET STATISTICS 0
Surely there can be others.)

Patch attached that adds the USING clause replacing the WITH clause,
which is also optional and only accepts statistic types (it doesn't
accept "foo = OFF" anymore, as it seems pointless, but I'm open to
accepting it if people care about it.)

(This patch removes WITH, but I verified that bison accepts having both.
The second attached reversed patch is what I used for removal.)

In the meantime, I noticed that pg_dump support for extstats is not
covered, which I'll go fix next.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera wrote:

In the meantime, I noticed that pg_dump support for extstats is not
covered, which I'll go fix next.

Here I add one, which seems to work for me.

Considering that Stephen missed a terminating semicolon for test with
create_order 96 (the last one prior to my commit) in commit
31a8b77a9244, I propose that we change whatever is concatenating those
strings append a terminating semicolon. (Surely we don't care about two
tests stanzas writing a single SQL command by omitting the semicolon
terminator.)

I wonder if there's any rationale to the create_order numbers. Surely
we only care for objects that depend on others.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Alvaro Herrera wrote:

In the meantime, I noticed that pg_dump support for extstats is not
covered, which I'll go fix next.

Here I add one, which seems to work for me.

Considering that Stephen missed a terminating semicolon for test with
create_order 96 (the last one prior to my commit) in commit
31a8b77a9244, I propose that we change whatever is concatenating those
strings append a terminating semicolon. (Surely we don't care about two
tests stanzas writing a single SQL command by omitting the semicolon
terminator.)

Whoops, sorry about that. Yes, we could pretty easily add that. The
create SQL is built up at the bottom of 002_pg_dump.pl:

$create_sql .= $tests{$test}->{create_sql};

I wonder if there's any rationale to the create_order numbers. Surely
we only care for objects that depend on others.

Yes, it was just a way to manage those dependencies. If there's value
in doing something more complicated then we could certainly do that, but
I'm not sure why it would be necessary to add that complexity.

Thanks!

Stephen

Alvaro Herrera wrote:

Simon Riggs wrote:

2.
USING keyword, no brackets
CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;

and if there are options, use the WITH for the optional parameters like this
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON
(a, b) FROM t1 WHERE partial-stuff;

I think I like (2)

OK, sounds sensible.

Yawn. So, we have not achieved the stated goal which was to get rid of
the ugly clause in the middle of the command; moreover we have gained
*yet another* clause in the middle of the command. Is this really an
improvement? We're trading this
CREATE STATISTICS s1 WITH (dependencies, ndistinct, options) ON (a, b) FROM t1 WHERE partial-stuff;
for this:
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON (a, b) FROM t1 WHERE partial-stuff;

Can we decide by a show of hands, please, whether we're really on board
with this change?

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Stephen Frost wrote:

Here I add one, which seems to work for me.

Pushed it -- I also added another one which specifies options, to test
WITH handling in ruleutils.

Considering that Stephen missed a terminating semicolon for test with
create_order 96 (the last one prior to my commit) in commit
31a8b77a9244, I propose that we change whatever is concatenating those
strings append a terminating semicolon. (Surely we don't care about two
tests stanzas writing a single SQL command by omitting the semicolon
terminator.)

Whoops, sorry about that. Yes, we could pretty easily add that. The
create SQL is built up at the bottom of 002_pg_dump.pl:

$create_sql .= $tests{$test}->{create_sql};

Okay, I added it.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Yawn. So, we have not achieved the stated goal which was to get rid of
the ugly clause in the middle of the command; moreover we have gained
*yet another* clause in the middle of the command. Is this really an
improvement? We're trading this
CREATE STATISTICS s1 WITH (dependencies, ndistinct, options) ON (a, b) FROM t1 WHERE partial-stuff;
for this:
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON (a, b) FROM t1 WHERE partial-stuff;

Can we decide by a show of hands, please, whether we're really on board
with this change?

That seems totally messy :-(

I can't see any good reason why "WITH (options)" can't be at the end of
the query. WITH is a fully reserved word, there is not going to be any
danger of a parse problem from having it follow the FROM or WHERE clauses.
And the end is where we have other instances of "WITH (options)".

It also seems like we don't need to have *both* fully-reserved keywords
introducing each clause *and* parentheses around the lists. Maybe
dropping the parens around the stats-types list and the column-names
list would help to declutter? (But I'd keep parens around the WITH
options, for consistency with other statements.)

One other point is that as long as we've got reserved keywords introducing
each clause, there isn't actually an implementation reason why we couldn't
accept the clauses in any order. Not sure I want to document it that way,
but it might not be a bad thing if the grammar was forgiving about whether
you write the USING or ON part first ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/03/2017 04:42 PM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Yawn. So, we have not achieved the stated goal which was to get rid of
the ugly clause in the middle of the command; moreover we have gained
*yet another* clause in the middle of the command. Is this really an
improvement? We're trading this
CREATE STATISTICS s1 WITH (dependencies, ndistinct, options) ON (a, b) FROM t1 WHERE partial-stuff;
for this:
CREATE STATISTICS s1 USING (dependencies, ndistinct) WITH (options) ON (a, b) FROM t1 WHERE partial-stuff;
Can we decide by a show of hands, please, whether we're really on board
with this change?

That seems totally messy :-(

I can't see any good reason why "WITH (options)" can't be at the end of
the query. WITH is a fully reserved word, there is not going to be any
danger of a parse problem from having it follow the FROM or WHERE clauses.
And the end is where we have other instances of "WITH (options)".

It also seems like we don't need to have *both* fully-reserved keywords
introducing each clause *and* parentheses around the lists. Maybe
dropping the parens around the stats-types list and the column-names
list would help to declutter? (But I'd keep parens around the WITH
options, for consistency with other statements.)

One other point is that as long as we've got reserved keywords introducing
each clause, there isn't actually an implementation reason why we couldn't
accept the clauses in any order. Not sure I want to document it that way,
but it might not be a bad thing if the grammar was forgiving about whether
you write the USING or ON part first ...

+1 for allowing arbitrary order of clauses. I would document it with the
USING clause at the end, and have that be what psql supports and pg_dump
produces. Since there are no WITH options now we should leave that out
until it's required.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan wrote:

On 05/03/2017 04:42 PM, Tom Lane wrote:

One other point is that as long as we've got reserved keywords introducing
each clause, there isn't actually an implementation reason why we couldn't
accept the clauses in any order. Not sure I want to document it that way,
but it might not be a bad thing if the grammar was forgiving about whether
you write the USING or ON part first ...

+1 for allowing arbitrary order of clauses. I would document it with the
USING clause at the end, and have that be what psql supports and pg_dump
produces. Since there are no WITH options now we should leave that out
until it's required.

Ok, sounds good to me. Unless there are objections I'm going to have a
shot at implementing this. Thanks for the discussion.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 5/3/17 11:36 PM, Alvaro Herrera wrote:

Andrew Dunstan wrote:

On 05/03/2017 04:42 PM, Tom Lane wrote:

One other point is that as long as we've got reserved keywords introducing
each clause, there isn't actually an implementation reason why we couldn't
accept the clauses in any order. Not sure I want to document it that way,
but it might not be a bad thing if the grammar was forgiving about whether
you write the USING or ON part first ...

+1 for allowing arbitrary order of clauses. I would document it with the
USING clause at the end, and have that be what psql supports and pg_dump
produces. Since there are no WITH options now we should leave that out
until it's required.

Ok, sounds good to me. Unless there are objections I'm going to have a
shot at implementing this. Thanks for the discussion.

Works for me. Do you also plan to remove the parentheses for the USING
clause?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3 May 2017 at 23:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:

It also seems like we don't need to have *both* fully-reserved keywords
introducing each clause *and* parentheses around the lists. Maybe
dropping the parens around the stats-types list and the column-names
list would help to declutter? (But I'd keep parens around the WITH
options, for consistency with other statements.)

+1

One other point is that as long as we've got reserved keywords introducing
each clause, there isn't actually an implementation reason why we couldn't
accept the clauses in any order. Not sure I want to document it that way,
but it might not be a bad thing if the grammar was forgiving about whether
you write the USING or ON part first ...

+1 for allowing arbitrary order of clauses.

+1

I would document it with the
USING clause at the end, and have that be what psql supports and pg_dump
produces. Since there are no WITH options now we should leave that out
until it's required.

Let's record the target syntax in parser comments so we can just slot
things in when needed later, without rediscussion.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers