Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm. That would behave less than desirably if getObjectClass() could
>> return a value that wasn't a member of the enum, but it's hard to
>> credit that happening. I guess I'd vote for removing the default:
>> case from all of the places that have "swit
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Oh, I see your patch also fixes missing code in getObjectDescription().
> >> We need that. Is there a decent way to get the compiler to warn about
> >> that oversight?
>
> > We could remove the default clause. That results in the
Alvaro Herrera writes:
> Tom Lane wrote:
>> Oh, I see your patch also fixes missing code in getObjectDescription().
>> We need that. Is there a decent way to get the compiler to warn about
>> that oversight?
> We could remove the default clause. That results in the expected
> warning, and no ot
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Oh, sorry --- I already pushed something about this.
>
> > That's fine, thanks.
>
> Oh, I see your patch also fixes missing code in getObjectDescription().
> We need that. Is there a decent way to get the compiler to warn about
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> Oh, sorry --- I already pushed something about this.
> That's fine, thanks.
Oh, I see your patch also fixes missing code in getObjectDescription().
We need that. Is there a decent way to get the compiler to warn about
that oversight?
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Although I've not done anything about it here, I'm not happy about the
> >> handling of dependencies for stats objects.
>
> > Here are two patches regarding handling of dependencies.
>
> Oh, sorry --- I already pushed something ab
Alvaro Herrera writes:
> Tom Lane wrote:
>> Although I've not done anything about it here, I'm not happy about the
>> handling of dependencies for stats objects.
> Here are two patches regarding handling of dependencies.
Oh, sorry --- I already pushed something about this.
> The first one
> imp
Tom Lane wrote:
> Although I've not done anything about it here, I'm not happy about the
> handling of dependencies for stats objects. I do not think that cloning
> RemoveStatistics as RemoveStatisticsExt is sane at all. The former is
> meant to deal with cleaning up pg_statistic rows that we kn
I wrote:
> Tomas Vondra writes:
>> On 5/12/17 4:46 AM, Tom Lane wrote:
>>> Although I've not done anything about it here, I'm not happy about the
>>> handling of dependencies for stats objects.
>> Yeah, it's a bit frankensteinian ...
> I'm prepared to create a fix for that, but it'd be easier to
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I'm prepared to create a fix for that, but it'd be easier to commit the
> >> current patch first, to avoid merge conflicts.
>
> > It seems we're mostly in agreement regarding the parts I was touching.
> > Do you want to push your v
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm prepared to create a fix for that, but it'd be easier to commit the
>> current patch first, to avoid merge conflicts.
> It seems we're mostly in agreement regarding the parts I was touching.
> Do you want to push your version of the patch?
It's sti
Tom Lane wrote:
> Tomas Vondra writes:
> >> Although I've not done anything about it here, I'm not happy about the
> >> handling of dependencies for stats objects.
>
> > Yeah, it's a bit frankensteinian ...
>
> I'm prepared to create a fix for that, but it'd be easier to commit the
> current pa
Tomas Vondra writes:
> On 5/12/17 4:46 AM, Tom Lane wrote:
>> If people agree that that reads better, we should make an effort to
>> propagate that terminology elsewhere in the docs, and into error messages,
>> objectaddress.c output, etc.
> I'm fine with the 'statistics object' wording. I've bee
On 5/12/17 4:46 AM, Tom Lane wrote:
Alvaro Herrera writes:
Hmm, yeah, makes sense. Here's a patch for this approach.
...
Also, while reading the docs changes, I got rather ill from the
inconsistent and not very grammatical handling of "statistics" as a
noun, particularly the inability to
Alvaro Herrera writes:
> Hmm, yeah, makes sense. Here's a patch for this approach.
I did some code review on this patch. The attached update makes the
following hopefully-uncontroversial changes:
* fix inconsistencies in the set of fields in CreateStatsStmt
* get rid of struct CreateStatsArgu
Alvaro Herrera writes:
> BTW the new castNode() family of macros don't work with Value nodes
> (because the tags are different depending on what's stored, but each
> type does not have its own struct. Oh well.)
Yeah. Value nodes are pretty much of a wart --- it's not clear to me
that they add a
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Have you thought further about the upthread suggestion to just borrow
> >> SELECT's syntax lock stock and barrel?
>
> > Bison seems to like the productions below. Is this what you had in
> > mind? These mostly mimic joined_table
Alvaro Herrera writes:
> Tom Lane wrote:
>> Have you thought further about the upthread suggestion to just borrow
>> SELECT's syntax lock stock and barrel?
> Bison seems to like the productions below. Is this what you had in
> mind? These mostly mimic joined_table and table_ref, stripping out t
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hmm ... I'm not sure that I buy that particular argument. If you're
>> concerned that the grammar could not handle "FROM x JOIN y USING (z)",
>> wouldn't it also have a problem with "FROM x JOIN y ON (z)"?
> Tomas spent some time trying to shoehorn the
Tom Lane wrote:
> Hmm ... I'm not sure that I buy that particular argument. If you're
> concerned that the grammar could not handle "FROM x JOIN y USING (z)",
> wouldn't it also have a problem with "FROM x JOIN y ON (z)"?
>
> It might work anyway, since the grammar should know whether ON or USIN
On 04.05.2017 23:13, Tom Lane wrote:
I'm not against what you've done here, because I had no love for USING
in this context anyway; it conveys approximately nothing to the mind
about what is in the list it's introducing. But I'm concerned whether
we're boxing ourselves in by using ON.
Actually,
Alvaro Herrera writes:
> Here's a patch implementing this idea. From gram.y's comment, the
> support syntax is now:
>
> /*
>*
>*QUERY :
> ! *CREATE STATISTICS stats_name [(stat types)]
Here's a patch implementing this idea. From gram.y's comment, the
support syntax is now:
/*
*
*QUERY :
! *CREATE STATISTICS stats_name [(stat types)] arguments
!
! *where 'ar
On 3 May 2017 at 23:31, Andrew Dunstan 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?
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. No
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 w
On 05/03/2017 04:42 PM, Tom Lane wrote:
> Alvaro Herrera 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
>> improve
Alvaro Herrera 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 STATISTIC
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)
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 USIN
Alvaro,
* Alvaro Herrera (alvhe...@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 sem
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 co
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 (option
On 22 April 2017 at 21:30, Simon Riggs 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 I
2017-04-22 11:30 GMT+02:00 Simon Riggs :
> On 21 April 2017 at 01:21, Tomas Vondra
> wrote:
> > On 04/21/2017 12:13 AM, Tom Lane wrote:
> >>
> >> Alvaro Herrera writes:
> >>>
> >>> Simon just pointed out that having the WITH clause appear in the middle
> >>> of the CREATE STATISTICS command look
On 21 April 2017 at 01:21, Tomas Vondra wrote:
> On 04/21/2017 12:13 AM, Tom Lane wrote:
>>
>> Alvaro Herrera 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
On 21 April 2017 at 01:21, Tomas Vondra wrote:
> On 04/21/2017 12:13 AM, Tom Lane wrote:
>>
>> Alvaro Herrera 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
Moin,
On Fri, April 21, 2017 7:04 am, David Rowley wrote:
> On 21 April 2017 at 22:30, Tels 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, exp
On 21 April 2017 at 22:30, Tels 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
Moin,
On Thu, April 20, 2017 8:21 pm, Tomas Vondra wrote:
> On 04/21/2017 12:13 AM, Tom Lane wrote:
>> Alvaro Herrera 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 04/21/2017 12:13 AM, Tom Lane wrote:
Alvaro Herrera 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,
Alvaro Herrera 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
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 patc
Hannu Krosing <[EMAIL PROTECTED]> writes:
> SELECT x.*
> FROM x,
> (select match (x.foo, '([0-9]+)x([0-9]+)')
> from x innerx
>where innerx.pk = x.pk
>) as res
> HAVING y = get_match_group(res, 2)
> OR y = get_match_group(res, 3)
> ;
Well you don't need to go
David Fetter kirjutas L, 13.12.2003 kell 23:17:
> On Sat, Dec 13, 2003 at 10:58:59PM +0200, Hannu Krosing wrote:
> > David Fetter kirjutas R, 12.12.2003 kell 20:13:
> > > Kind people,
>
> > > I'm looking to the SQL WITH clause as a way to get better regex
> > > support in PostgreSQL. I've been ch
On Sat, Dec 13, 2003 at 10:58:59PM +0200, Hannu Krosing wrote:
> David Fetter kirjutas R, 12.12.2003 kell 20:13:
> > Kind people,
> > I'm looking to the SQL WITH clause as a way to get better regex
> > support in PostgreSQL. I've been chatting a little bit about
> > this, and here's an idea for a
David Fetter kirjutas R, 12.12.2003 kell 20:13:
> Kind people,
>
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
>
> WITH res = match (x.foo, '
On Sat, 13 Dec 2003, Christopher Browne wrote:
> Unfortunately, this doesn't seem to fit with the way WITH is defined
> in SQL.
How is the WITH construct defined in SQL?
--
/Dennis
---(end of broadcast)---
TIP 7: don't forget to increase your fr
[EMAIL PROTECTED] (David Fetter) wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
>
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELEC
In article <[EMAIL PROTECTED]> you wrote:
> On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote:
>
>> I'm looking to the SQL WITH clause as a way to get better regex
>> support in PostgreSQL. I've been chatting a little bit about this,
>> and here's an idea for a behavior. Implementatio
On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
I think you could be rather looki
On Fri, Dec 12, 2003 at 07:47:26PM +0100, Peter Eisentraut wrote:
> David Fetter wrote:
> > I'm looking to the SQL WITH clause as a way to get better regex
> > support in PostgreSQL. I've been chatting a little bit about
> > this, and here's an idea for a behavior. Implementation details
> > TBD.
David Fetter <[EMAIL PROTECTED]> writes:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELEC
David Fetter wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
>
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELECT *
> FROM x
> WHERE
Kind people,
I'm looking to the SQL WITH clause as a way to get better regex
support in PostgreSQL. I've been chatting a little bit about this,
and here's an idea for a behavior. Implementation details TBD.
WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
SELECT *
FROM x
WHERE y = res[2]
ORy =
57 matches
Mail list logo
