Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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. > >

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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,

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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.

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Here's a patch implementing this idea. From gram.y's comment, the > support syntax is now: > > /* >* >*QUERY : > ! *CREATE

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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.

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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.

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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)

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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:

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

Re: [HACKERS] WITH clause in CREATE STATISTICS

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

[HACKERS] WITH clause in CREATE STATISTICS

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

[HACKERS] WHERE clause not used when index is used (9.5)

Placing this specific message onto -bugs while keeping -hackers and removing -novice. Editing subject to include version and remove list identifiers. There is continuing discussion on -hackers though mostly about how to do this right in the future. The specific problem stems from an attempted

Re: [HACKERS] VALUES clause memory optimization

Bruce Momjian wrote: Has this been addressed? Tom Lane wrote: The reason we could safely list_free inside transformInsertRow is that we know all its callers have just built the passed-in list and so there are no other pointers to it. That doesn't apply in the general case of grammar output.

Re: [HACKERS] VALUES clause memory optimization

Has this been addressed? --- Joe Conway wrote: Tom Lane wrote: The reason we could safely list_free inside transformInsertRow is that we know all its callers have just built the passed-in list and so there are no

Re: [HACKERS] VALUES clause memory optimization (was: Values list-of-targetlists patch...)

Joe Conway [EMAIL PROTECTED] writes: In transformExpr the comment implies that it should be safe to reapply to an already transformed expression. What if we free the raw_parser expression list/cells/nodes and replace it with the as-transformed one? How are you going to do the replace bit? The

Re: [HACKERS] VALUES clause memory optimization

Tom Lane wrote: The reason we could safely list_free inside transformInsertRow is that we know all its callers have just built the passed-in list and so there are no other pointers to it. That doesn't apply in the general case of grammar output. What about for the specific case of an

Re: [HACKERS] VALUES clause memory optimization

Joe Conway [EMAIL PROTECTED] writes: What about for the specific case of an InsertStmt? It seems that we could at least get away with freeing the raw-expression list in that case. Not sure ... what about rules, BETWEEN, yadda yadda? In terms of freeing an entire arbitrary node, could we

[HACKERS] VALUES clause memory optimization (was: Values list-of-targetlists patch...)

Tom Lane wrote: I think we could safely list_free the input list in transformInsertRow as your patch suggests, which would buy back the 144M part. But I don't believe it's safe at all to free the raw_parser output --- the grammar sometimes makes multiple links to the same subtree, eg in

Re: [HACKERS] WITH clause

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

Re: [HACKERS] WITH clause

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,

Re: [HACKERS] WITH clause

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

Re: [HACKERS] WITH clause

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 chatting a

Re: [HACKERS] WITH clause

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 fetch from

[HACKERS] WITH clause

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

Re: [HACKERS] WITH clause

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 y =

Re: [HACKERS] WITH clause

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]+)') SELECT *

Re: [HACKERS] WITH clause

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. WITH

Re: [HACKERS] WITH clause

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 looking

Re: [HACKERS] WITH clause

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. Implementation details

Re: [HACKERS] WITH clause

[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]+)') SELECT *

Re: [HACKERS] 4 Clause license?

On Thu, 2003-11-20 at 08:34, Rod Taylor wrote: I think maybe the simplest thing is for me to prepare a patch that rips that code out and replaces it with a (slightly simpler - less umask hacking required, I think) piece of code that I will write. The FreeBSD folks sorted it out for us.

Re: [HACKERS] 4 Clause license?

This whole thing is starting to make my head hurt. There has been more effort spent over this license issue than I would have spent if I hadn't taken the shortcut of using the FreeBSD code. I think maybe the simplest thing is for me to prepare a patch that rips that code out and replaces it

Re: [HACKERS] 4 Clause license?

I think maybe the simplest thing is for me to prepare a patch that rips that code out and replaces it with a (slightly simpler - less umask hacking required, I think) piece of code that I will write. The FreeBSD folks sorted it out for us. Everyones names should be in the copyright for the

Re: [HACKERS] 4 Clause license?

Rod Taylor wrote: I think maybe the simplest thing is for me to prepare a patch that rips that code out and replaces it with a (slightly simpler - less umask hacking required, I think) piece of code that I will write. The FreeBSD folks sorted it out for us. Everyones names should be in

Re: [HACKERS] 4 Clause license?

Rod Taylor wrote: I think maybe the simplest thing is for me to prepare a patch that rips that code out and replaces it with a (slightly simpler - less umask hacking required, I think) piece of code that I will write. The FreeBSD folks sorted it out for us. Everyones names should be

Re: [HACKERS] 4 Clause license?

On Thu, 20 Nov 2003, Andrew Dunstan wrote: trollOf course, now that SCO is claiming ownership of BSD code . /troll Interesting thread that ... last I read on the FreeBSD lists was speculation that they would be going after ppl like Cisco (re: TCP/IP Networking Code) since there really is

Re: [HACKERS] 4 Clause license?

Based on the below wouldn't they also have to go after Microsoft? Marc G. Fournier wrote: On Thu, 20 Nov 2003, Andrew Dunstan wrote: trollOf course, now that SCO is claiming ownership of BSD code . /troll Interesting thread that ... last I read on the FreeBSD lists was speculation

Re: [HACKERS] 4 Clause license?

On Thu, 20 Nov 2003, Joshua D. Drake wrote: Based on the below wouldn't they also have to go after Microsoft? Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I know that Linux is not using BSD TCP/IP (or, at least, they didn't in their first 3 incarnations of the stack)

Re: [HACKERS] 4 Clause license?

Marc G. Fournier wrote: On Thu, 20 Nov 2003, Joshua D. Drake wrote: Based on the below wouldn't they also have to go after Microsoft? Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I know that Linux is not using BSD TCP/IP (or, at least, they didn't in their

Re: [HACKERS] 4 Clause license?

--On Thursday, November 20, 2003 16:00:44 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2003, Joshua D. Drake wrote: Based on the below wouldn't they also have to go after Microsoft? Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I know that Linux is

Re: [HACKERS] 4 Clause license?

Hello, My understanding is that they use the BSD stack (at least as the basis) for TCP/IP. Windows that is. J Marc G. Fournier wrote: On Thu, 20 Nov 2003, Joshua D. Drake wrote: Based on the below wouldn't they also have to go after Microsoft? Depends ... does MicroSoft use BSD

Re: [HACKERS] 4 Clause license?

On Mon, 17 Nov 2003 14:48:08 -0500 Rod Taylor [EMAIL PROTECTED] wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 This appears to be an original

Re: [HACKERS] 4 Clause license?

On Mon, Nov 17, 2003 at 02:48:08PM -0500, Rod Taylor wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause

Re: [HACKERS] 4 Clause license?

On 2003.11.17 14:48:08 -0500, Rod Taylor wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause license or

[HACKERS] 4 Clause license?

The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 Is this intentionally under the 4 clause license or does the copyright from the website (2 clause) applied

[HACKERS] FROM clause omitted

I had a bug in one of my queries that wasn't detected by pg because if filled in the from clause by itself. Take for example a querie like select foo.a; which I guess is transformed to select foo.a from foo; Is this really a good thing to do? Is it part of the standard? Can it be turned of?

Re: [HACKERS] FROM clause omitted

Is this really a good thing to do? Is it part of the standard? Can it be turned of? In my case it hid a bug and made my query work but produce the wrong result. 7.4 has a switch to turn this off for the same reasons you cite. signature.asc Description: This is a digitally signed message part

Re: [HACKERS] FROM clause omitted

I had a bug in one of my queries that wasn't detected by pg because if filled in the from clause by itself. Take for example a querie like select foo.a; which I guess is transformed to select foo.a from foo; Is this really a good thing to do? Is it part of the standard? Can it be

Re: [HACKERS] FROM clause omitted

On Wed, Jul 16, 2003 at 08:29:01 +0200, Dennis Björklund [EMAIL PROTECTED] wrote: I had a bug in one of my queries that wasn't detected by pg because if filled in the from clause by itself. Take for example a querie like Currently this is the only way to use additional tables when doing a