Re: [HACKERS] wCTE: about the name of the feature

2011-02-28 Thread Marko Tiikkaja

On 2011-02-28 8:20 AM +0200, Tom Lane wrote:

Marko Tiikkajamarko.tiikk...@cs.helsinki.fi  writes:

On 2011-02-24 6:40 PM, I wrote:

I am planning on working on the documentation this weekend.



And here's my attempt.  The language is a bit poor at some places but I
can't think of anything better.


Applied after some rather heavy editorialization.


Thanks again.


I tried to be more strict about using subquery when talking about
WITHs in general since INSERT/UPDATE/DELETE is not a subquery in my book.


I undid most of those changes --- it didn't seem to add anything to be
strict in this way, and anyway you hadn't done it consistently,
eg the syntax still had with_query.


I wasn't so sure about those changes either.  It does seem more 
consistent this way.



Regards,
Marko Tiikkaja

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-27 Thread Marko Tiikkaja

On 2011-02-24 6:40 PM, I wrote:

I am planning on working on the documentation this weekend.


And here's my attempt.  The language is a bit poor at some places but I 
can't think of anything better.


I tried to be more strict about using subquery when talking about 
WITHs in general since INSERT/UPDATE/DELETE is not a subquery in my book.



Regards,
Marko Tiikkaja
*** a/doc/src/sgml/queries.sgml
--- b/doc/src/sgml/queries.sgml
***
*** 1526,1532  SELECT replaceableselect_list/replaceable FROM 
replaceabletable_expression
  
  
   sect1 id=queries-with
!   titleliteralWITH/literal Queries (Common Table Expressions)/title
  
indexterm zone=queries-with
 primaryWITH/primary
--- 1526,1532 
  
  
   sect1 id=queries-with
!   titleliteralWITH/literal Statements (Common Table Expressions)/title
  
indexterm zone=queries-with
 primaryWITH/primary
***
*** 1539,1549  SELECT replaceableselect_list/replaceable FROM 
replaceabletable_expression
/indexterm
  
para
!literalWITH/ provides a way to write subqueries for use in a larger
!query.  The subqueries, which are often referred to as Common Table
 Expressions or acronymCTE/acronyms, can be thought of as defining
!temporary tables that exist just for this query.  One use of this feature
!is to break down complicated queries into simpler parts.  An example is:
  
  programlisting
  WITH regional_sales AS (
--- 1539,1559 
/indexterm
  
para
!literalWITH/ provides a way to write auxiliary statements for use in a
!larger query.  These statements, which are often referred to as Common 
Table
 Expressions or acronymCTE/acronyms, can be thought of as defining
!temporary tables that exist just for this query.
!   /para
! 
!  sect2 id=subqueries-with
!titleSELECT Queries/title
! 
!indexterm
! primary*/primary
!/indexterm
!   para
!One use of this feature is to break down complicated queries into simpler
!parts.  An example is:
  
  programlisting
  WITH regional_sales AS (
***
*** 1806,1811  SELECT n FROM t LIMIT 100;
--- 1816,1917 
 In each case it effectively provides temporary table(s) that can
 be referred to in the main command.
/para
+  /sect2
+  sect2 id=modifying-with
+titleData-Modifying Statements/title
+ 
+indexterm
+ primary*/primary
+/indexterm
+ 
+para
+ You can also use data-modifying statements commandINSERT/,
+ commandUPDATE/ and commandDELETE/ in literalWITH/.  This 
allows
+ you to perform many different operations in the same query.  An example 
is:
+ 
+ programlisting
+ WITH moved_rows AS (
+ DELETE FROM ONLY products
+ WHERE
+ date gt;= '2010-10-01' AND
+ date lt; '2010-11-01'
+ RETURNING *
+ )
+ INSERT INTO products_log
+ SELECT * FROM moved_rows;
+ /programlisting
+ 
+ which moves rows from products to products_log.  In the example above,
+ the literalWITH/ clause is attached to the commandINSERT/, not the
+ commandSELECT/.  This is important, because data-modifying statements
+ are not allowed in literalWITH/ clauses which are not attached to the
+ top level statement.  However, normal literalWITH/ visibility rules
+ apply: it is possible to refer to a data-modifying literalWITH/ from a
+ subquery.
+/para
+ 
+para
+ Recursive self-references in data-modifying statements are not
+ allowed.  In some cases it is possible to work around this limitation by
+ referring to the output of a recursive literalWITH/:
+ 
+ programlisting
+ WITH RECURSIVE included_parts(sub_part, part) AS (
+ SELECT sub_part, part FROM parts WHERE part = 'our_product'
+   UNION ALL
+ SELECT p.sub_part, p.part
+ FROM included_parts pr, parts p
+ WHERE p.part = pr.sub_part
+   )
+ DELETE FROM parts
+   WHERE part IN (SELECT part FROM included_parts);
+ /programlisting
+ 
+ The above query would remove all direct and indirect subparts of a 
product.
+/para
+ 
+para
+ The execution of data-modifying statements in literalWITH/ is
+ interleaved with the main plan, and the order in which the statements
+ are executed is arbitrary.  The changes made by data-modifying statements
+ are not visible to the query.
+/para
+important
+ para
+  Trying to update the same row twice in a single command is not supported.
+  Only one of the modifications takes place, but it is not easy (and
+  sometimes not possible) to reliably predict which one.  This also applies
+  to deleting a row that was already updated in the same command; only the
+  update is performed.  You should generally avoid trying to modify a 
single
+  row twice in a single command.
+ /para
+/important
+ 
+para
+ Data-modifying statements are executed exactly once, and always to
+ completion.  If a literalWITH/ containing a data-modifying statement
+ is not 

Re: [HACKERS] wCTE: about the name of the feature

2011-02-27 Thread Tom Lane
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-24 6:40 PM, I wrote:
 I am planning on working on the documentation this weekend.

 And here's my attempt.  The language is a bit poor at some places but I 
 can't think of anything better.

Thanks, will work on this next.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-27 Thread Tom Lane
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-24 6:40 PM, I wrote:
 I am planning on working on the documentation this weekend.

 And here's my attempt.  The language is a bit poor at some places but I 
 can't think of anything better.

Applied after some rather heavy editorialization.

 I tried to be more strict about using subquery when talking about 
 WITHs in general since INSERT/UPDATE/DELETE is not a subquery in my book.

I undid most of those changes --- it didn't seem to add anything to be
strict in this way, and anyway you hadn't done it consistently,
eg the syntax still had with_query.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-26 Thread Marko Tiikkaja

On 2011-02-26 4:41 AM +0200, Tom Lane wrote:

Marko Tiikkajamarko.tiikk...@cs.helsinki.fi  writes:

One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in WITH?


That test was in your patch, no?  I moved the code to another place
but it's still enforcing the same thing, namely that you can't reference
the output of an INSERT/UPDATE/DELETE that hasn't got RETURNING.


Oh, right.  I misunderstood.


Regards,
Marko Tiikkaja

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-26 Thread David Fetter
On Sat, Feb 26, 2011 at 12:52:40AM -0500, Robert Haas wrote:
 On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
  Robert Haas robertmh...@gmail.com writes:
  Yay!  I'm excited about this, particularly the possible pipelining
  stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ...  and
  have it be like cool and fast and stuff.
 
  Or at least I hope you can do that.
 
  It's gonna need some work yet.  As things stand, the tuples are indeed
  pipelined through, but the CteScan nodes *also* stash them aside into
  tuplestores, just in case somebody demands a rescan.  Fixing that will
  require revisiting the exec flags (EXEC_FLAG_REWIND etc).  We don't
  currently distinguish it's unlikely you'll have to rescan from
  you're guaranteed not to have to rescan, but a CteScan that's covering
  a ModifyTable has to know the latter to not have to keep hold of copies
  of the RETURNING tuples.
 
  It might be a small enough change to do after alpha starts, but I don't
  have time for it right now.
 
 Well, if nothing else, the potential is there for a future release.

That's kinda where I am on this one.  In the grand PostgreSQL
tradition, we can have something that works before we have something
that works fast :)

 I'm probably not quite as excited about this feature as David Fetter

Heh!

 (and my 100-Watt lightbulb is not quite as bright as the sun at high
 noon in midsummer) but I do think it's pretty cool, and I appreciate
 you getting it in, even in a somewhat basic form.

Me, too!

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Tom Lane
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
 OK, I will make those adjustments.  Are you going to do more work on the
 documentation part of the patch?  I can stick to working on the code
 part meanwhile, if you are.

 I am planning on working on the documentation this weekend.

I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.
I'll wait on you to produce documentation updates before dealing
with the docs, but I figured we might as well get some buildfarm
cycles on it meanwhile.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Marko Tiikkaja

On 2011-02-26 2:00 AM, Tom Lane wrote:

I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.


Thanks a lot!

One thing bothers me though: what was the reason for requiring a 
RETURNING clause for data-modifying statements in WITH?



I'll wait on you to produce documentation updates before dealing
with the docs, but I figured we might as well get some buildfarm
cycles on it meanwhile.


Thanks, I'll send an improved version tomorrow.


Regards,
Marko Tiikkaja

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Tom Lane
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-26 2:00 AM, Tom Lane wrote:
 I've gone ahead and applied the code portion of the patch, with
 modifications as per discussion, and other editorialization.

 Thanks a lot!

 One thing bothers me though: what was the reason for requiring a 
 RETURNING clause for data-modifying statements in WITH?

That test was in your patch, no?  I moved the code to another place
but it's still enforcing the same thing, namely that you can't reference
the output of an INSERT/UPDATE/DELETE that hasn't got RETURNING.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread David Fetter
On Thu, Feb 24, 2011 at 11:20:48AM -0500, Tom Lane wrote:
 The wCTE patch refers to the feature it's adding as DML WITH.  I'm
 still pretty unhappy with that terminology.  In my view of the world,
 DML includes SELECT as well as INSERT/UPDATE/DELETE.  The wikipedia
 entry about the term
 http://en.wikipedia.org/wiki/Data_Manipulation_Language
 agrees that that's at least the majority usage, and even our own docs
 seem to use it to include SELECT as often as not.  Since the distinction
 is absolutely critical to talking about this feature sensibly, I don't
 think it's a good plan to use an acronym that is guaranteed to produce
 uncertainty in the reader's mind.
 
 The best idea I have at the moment is to spell out data modifying
 command (or statement) rather than relying on the acronym.
 In the code, we could change hasDmlWith to hasModifyingWith, for
 example.  The error messages could read like
   data-modifying statement in WITH is not allowed in a view
 
 Comments?

+1

If we ever decide add in what I'd originally envisioned, namely DCL
and DDL, the name continues to describe what's going on :)

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread David Fetter
On Thu, Feb 24, 2011 at 11:35:30AM -0800, David Wheeler wrote:
 On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
 
  The best idea I have at the moment is to spell out data modifying
  command (or statement) rather than relying on the acronym.
  In the code, we could change hasDmlWith to hasModifyingWith, for
  example.  The error messages could read like
 data-modifying statement in WITH is not allowed in a view
  
  Comments?
  
  Great idea.  I had the same complaint when I looked at this patch
  a year ago, but didn't come up with nearly as good an idea as to
  what to do about it.
 
 I like statement better than command, too, but love the acronym
 DMC. As in, you want to Run [a] DMC. ;-P

Hit it, Run! ;)

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Robert Haas
On Fri, Feb 25, 2011 at 7:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
 OK, I will make those adjustments.  Are you going to do more work on the
 documentation part of the patch?  I can stick to working on the code
 part meanwhile, if you are.

 I am planning on working on the documentation this weekend.

 I've gone ahead and applied the code portion of the patch,

Yay!  I'm excited about this, particularly the possible pipelining
stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ...  and
have it be like cool and fast and stuff.

Or at least I hope you can do that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 Yay!  I'm excited about this, particularly the possible pipelining
 stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ...  and
 have it be like cool and fast and stuff.

 Or at least I hope you can do that.

It's gonna need some work yet.  As things stand, the tuples are indeed
pipelined through, but the CteScan nodes *also* stash them aside into
tuplestores, just in case somebody demands a rescan.  Fixing that will
require revisiting the exec flags (EXEC_FLAG_REWIND etc).  We don't
currently distinguish it's unlikely you'll have to rescan from
you're guaranteed not to have to rescan, but a CteScan that's covering
a ModifyTable has to know the latter to not have to keep hold of copies
of the RETURNING tuples.

It might be a small enough change to do after alpha starts, but I don't
have time for it right now.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-25 Thread Robert Haas
On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 Yay!  I'm excited about this, particularly the possible pipelining
 stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ...  and
 have it be like cool and fast and stuff.

 Or at least I hope you can do that.

 It's gonna need some work yet.  As things stand, the tuples are indeed
 pipelined through, but the CteScan nodes *also* stash them aside into
 tuplestores, just in case somebody demands a rescan.  Fixing that will
 require revisiting the exec flags (EXEC_FLAG_REWIND etc).  We don't
 currently distinguish it's unlikely you'll have to rescan from
 you're guaranteed not to have to rescan, but a CteScan that's covering
 a ModifyTable has to know the latter to not have to keep hold of copies
 of the RETURNING tuples.

 It might be a small enough change to do after alpha starts, but I don't
 have time for it right now.

Well, if nothing else, the potential is there for a future release.
I'm probably not quite as excited about this feature as David Fetter
(and my 100-Watt lightbulb is not quite as bright as the sun at high
noon in midsummer) but I do think it's pretty cool, and I appreciate
you getting it in, even in a somewhat basic form.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread Marko Tiikkaja

On 2011-02-24 6:20 PM +0200, Tom Lane wrote:

The wCTE patch refers to the feature it's adding as DML WITH.  I'm
still pretty unhappy with that terminology.  In my view of the world,
DML includes SELECT as well as INSERT/UPDATE/DELETE.  The wikipedia
entry about the term
http://en.wikipedia.org/wiki/Data_Manipulation_Language
agrees that that's at least the majority usage, and even our own docs
seem to use it to include SELECT as often as not.  Since the distinction
is absolutely critical to talking about this feature sensibly, I don't
think it's a good plan to use an acronym that is guaranteed to produce
uncertainty in the reader's mind.


Agreed.


The best idea I have at the moment is to spell out data modifying
command (or statement) rather than relying on the acronym.
In the code, we could change hasDmlWith to hasModifyingWith, for
example.  The error messages could read like
data-modifying statement in WITH is not allowed in a view

Comments?


Out of everything suggested so far, I think this is the best we have, if 
we can fit the whole thing into out error messages.  Quickly grepping 
through the patch suggests that we can, at least for the cases in the 
current patch.


I also prefer statement over command.


Regards,
Marko Tiikkaja

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread Tom Lane
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
 On 2011-02-24 6:20 PM +0200, Tom Lane wrote:
 The best idea I have at the moment is to spell out data modifying
 command (or statement) rather than relying on the acronym.
 In the code, we could change hasDmlWith to hasModifyingWith, for
 example.  The error messages could read like
  data-modifying statement in WITH is not allowed in a view
 
 Comments?

 Out of everything suggested so far, I think this is the best we have, if 
 we can fit the whole thing into out error messages.  Quickly grepping 
 through the patch suggests that we can, at least for the cases in the 
 current patch.

 I also prefer statement over command.

OK, I will make those adjustments.  Are you going to do more work on the
documentation part of the patch?  I can stick to working on the code
part meanwhile, if you are.

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread Marko Tiikkaja

On 2011-02-24 6:37 PM +0200, Tom Lane wrote:

OK, I will make those adjustments.  Are you going to do more work on the
documentation part of the patch?  I can stick to working on the code
part meanwhile, if you are.


I am planning on working on the documentation this weekend.


Regards,
Marko Tiikkaja

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread Andrew Dunstan



On 02/24/2011 11:20 AM, Tom Lane wrote:

The wCTE patch refers to the feature it's adding as DML WITH.  I'm
still pretty unhappy with that terminology.  In my view of the world,
DML includes SELECT as well as INSERT/UPDATE/DELETE.  The wikipedia
entry about the term
http://en.wikipedia.org/wiki/Data_Manipulation_Language
agrees that that's at least the majority usage, and even our own docs
seem to use it to include SELECT as often as not.  Since the distinction
is absolutely critical to talking about this feature sensibly, I don't
think it's a good plan to use an acronym that is guaranteed to produce
uncertainty in the reader's mind.

The best idea I have at the moment is to spell out data modifying
command (or statement) rather than relying on the acronym.
In the code, we could change hasDmlWith to hasModifyingWith, for
example.  The error messages could read like
data-modifying statement in WITH is not allowed in a view

Comments?



I think your're absolutely right. DML means that to me too. It's in 
effect the opposite of DDL.


log_statement used mod for this category of statements. If we need a 
new acronym, I modestly suggest CUD (CRUD without the R). The we could 
make all sorts of puns about chewing the CUD :-)


cheers

andrew

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread Robert Haas
On Thu, Feb 24, 2011 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 The wCTE patch refers to the feature it's adding as DML WITH.  I'm
 still pretty unhappy with that terminology.  In my view of the world,
 DML includes SELECT as well as INSERT/UPDATE/DELETE.  The wikipedia
 entry about the term
 http://en.wikipedia.org/wiki/Data_Manipulation_Language
 agrees that that's at least the majority usage, and even our own docs
 seem to use it to include SELECT as often as not.  Since the distinction
 is absolutely critical to talking about this feature sensibly, I don't
 think it's a good plan to use an acronym that is guaranteed to produce
 uncertainty in the reader's mind.

 The best idea I have at the moment is to spell out data modifying
 command (or statement) rather than relying on the acronym.
 In the code, we could change hasDmlWith to hasModifyingWith, for
 example.  The error messages could read like
        data-modifying statement in WITH is not allowed in a view

 Comments?

Great idea.  I had the same complaint when I looked at this patch a
year ago, but didn't come up with nearly as good an idea as to what to
do about it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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


Re: [HACKERS] wCTE: about the name of the feature

2011-02-24 Thread David E. Wheeler
On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:

 The best idea I have at the moment is to spell out data modifying
 command (or statement) rather than relying on the acronym.
 In the code, we could change hasDmlWith to hasModifyingWith, for
 example.  The error messages could read like
data-modifying statement in WITH is not allowed in a view
 
 Comments?
 
 Great idea.  I had the same complaint when I looked at this patch a
 year ago, but didn't come up with nearly as good an idea as to what to
 do about it.

I like statement better than command, too, but love the acronym DMC. As in, 
you want to Run [a] DMC. ;-P

David


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