Re: [DOCS] The Tutorial(TM)

[Jeroen Ruigrok/asmodai]

-On [20040108 07:32], Peter Eisentraut ([EMAIL PROTECTED]) wrote:
>Why?

Because foreign keys are part of database design 101?

-- 
Jeroen Ruigrok van der Werven  / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
It does not require many words to speak the truth...

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

[DOCS] ODBC encoding

[Karel Zak]

 Hi,

 docs for 7.3  contains information how set client  encoding for Windows
 ODBC, but in docs for 7.4 I can't found it. Is it right?

 http://www.postgresql.org/docs/7.3/static/multibyte.html

-- 
 Karel Zak  <[EMAIL PROTECTED]>
 http://home.zf.jcu.cz/~zakkr/

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [DOCS] The Tutorial(TM)

[David Fetter]

On Thu, Jan 08, 2004 at 08:52:29AM +0100, Jeroen Ruigrok/asmodai wrote:
> -On [20040108 07:32], Peter Eisentraut ([EMAIL PROTECTED]) wrote:

> >Why?

> Because foreign keys are part of database design 101?

Yes.

Expanding on that, putting FK's in "Advanced Features" gives the (IME
always wrong) impression that they're optional.

Chris Browne, could you give me a pointer to your patch so we don't
step on each other's feet?

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

[DOCS] psql documentation

[Halley Pacheco de Oliveira]

Reference Manual - psql entry:

In app-psql.html is witten:

Note: To simplify typing, commands that consists of
several words do not have to be quoted. Thus it is
fine to type \help alter table

So, I tried:

template1=# \help 'alter table'
No help available for ''alter table''.
Try \h with no arguments to see available help.
template1=# \help "alter table"
No help available for '"alter table"'.
Try \h with no arguments to see available help.

My conclusion is "can not be quoted" and not "do not
have to be quoted". I'm right ?

Halley

__

Conheça a nova central de informações anti-spam do Yahoo! Mail:
http://www.yahoo.com.br/antispam

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [DOCS] Updated Russian translation of FAQ

[Bruce Momjian]

Thanks.  Applied.

---

Viktor Vislobokov wrote:
> Hello All!
> 
>   There is updated Russian translation of FAQ in attachment
> 
> With best wishes,
> Victor Vislobokov
> Perm, Russia
> 

[ Attachment, skipping... ]

> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
>http://archives.postgresql.org

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [DOCS] The Tutorial(TM)

[Peter Eisentraut]

David Fetter wrote:
> Expanding on that, putting FK's in "Advanced Features" gives the (IME
> always wrong) impression that they're optional.

They *are* optional.

The first chapter is about getting the data in and out.  That is not 
optional for using a database.  Transactions, views, foreign keys, 
primary keys even, and everything else that some people think is 
essential for a "real" database are in fact optional.  Remember that 
the tutorial is intended for people starting from zero.  Let's not 
overwhelm them right away.


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [DOCS] The Tutorial(TM)

[Peter Eisentraut]

Jeroen Ruigrok/asmodai wrote:
> Because foreign keys are part of database design 101?

Indeed, but the subject matter of chapter 2 of the tutorial is more like 
introduction to databases 099.  Others may rightfully claim that 
transactions and views are also elementary parts of database 
application designs, but then there wouldn't be any advanced subjects 
left.

I feel that there is a very useful dividing line between chapters 2 and 
3: chapter 2 is about getting the data in and out, to give beginners a 
feeling that the database system is working, chapter 3 is about 
refining the data structures for higher convenience, maintainability, 
and integrity -- "design".


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [DOCS] The Tutorial(TM)

[Rod Taylor]

On Thu, 2004-01-08 at 12:07, Peter Eisentraut wrote:
> David Fetter wrote:
> > Expanding on that, putting FK's in "Advanced Features" gives the (IME
> > always wrong) impression that they're optional.
> 
> They *are* optional.
> 
> The first chapter is about getting the data in and out.  That is not 
> optional for using a database.  Transactions, views, foreign keys, 
> primary keys even, and everything else that some people think is 
> essential for a "real" database are in fact optional.  Remember that 
> the tutorial is intended for people starting from zero.  Let's not 
> overwhelm them right away.

Perhaps it's simply the wrong title.

"Design" in place of "Advanced Features"

They're not advanced database features, but they aren't required
learning until you're designing the environment rather than simply using
the environment.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [DOCS] The Tutorial(TM)

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I feel that there is a very useful dividing line between chapters 2 and 
> 3: chapter 2 is about getting the data in and out, to give beginners a 
> feeling that the database system is working, chapter 3 is about 
> refining the data structures for higher convenience, maintainability, 
> and integrity -- "design".

Perhaps a reasonable compromise would be to divide the material into 3
chapters instead of 2 --- beginner, intermediate, advanced.  Looking
at the existing TOC:

2. The SQL Language
 2.1. Introduction
 2.2. Concepts
 2.3. Creating a New Table
 2.4. Populating a Table With Rows
 2.5. Querying a Table
 2.6. Joins Between Tables
 2.7. Aggregate Functions
 2.8. Updates
 2.9. Deletions
3. Advanced Features
 3.1. Introduction
 3.2. Views
 3.3. Foreign Keys
 3.4. Transactions
 3.5. Inheritance
 3.6. Conclusion

I'd be inclined to put aggregates, transactions, foreign keys, and views
into the "intermediate" category, leaving only inheritance as
"advanced".  (Or maybe we should just drop inheritance from the tutorial.)
You could possibly even argue that joins are intermediate instead of
basic, although that's stretching it a bit.

I agree with Peter's point that the first thing to teach is how to get
data in and out.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [DOCS] The Tutorial(TM)

[Joshua D. Drake]

Peter Eisentraut wrote:

  Jeroen Ruigrok/asmodai wrote:
  
  
Because foreign keys are part of database design 101?

  
  
Indeed, but the subject matter of chapter 2 of the tutorial is more like 
introduction to databases 099.  Others may rightfully claim that 
transactions and views are also elementary parts of database 
application designs, but then there wouldn't be any advanced subjects 
left.

  

Triggers, rules, name spaces...

Foreign keys IMHO should be in a small chapter "About database design"
or "Making sure your data is valid"
or something.




  I feel that there is a very useful dividing line between chapters 2 and 
3: chapter 2 is about getting the data in and out, to give beginners a 
feeling that the database system is working, chapter 3 is about 
refining the data structures for higher convenience, maintainability, 
and integrity -- "design".


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match
  



-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org 

Re: [DOCS] The Tutorial(TM)

[David Fetter]

On Thu, Jan 08, 2004 at 06:07:13PM +0100, Peter Eisentraut wrote:
> David Fetter wrote:
> > Expanding on that, putting FK's in "Advanced Features" gives the
> > (IME always wrong) impression that they're optional.
> 
> They *are* optional.

I disagree.

> The first chapter is about getting the data in and out.  That is not
> optional for using a database.  Transactions, views, foreign keys,
> primary keys even, and everything else that some people think is
> essential for a "real" database are in fact optional.
> Remember that the tutorial is intended for people starting from
> zero.

No, they're not optional.  If people see how it's done right, starting
from zero, they will not then develop bad habits that have to be
un-learned.

> Let's not overwhelm them right away.

I don't think this will be overwhelming.

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [DOCS] The Tutorial(TM)

[David Fetter]

Christopher Browne <[EMAIL PROTECTED]> wrote:
> Oops! [EMAIL PROTECTED] (David Fetter) was seen spray-painting on a wall:
>> On Thu, Jan 08, 2004 at 06:07:13PM +0100, Peter Eisentraut wrote:
>>> David Fetter wrote:
>>> > Expanding on that, putting FK's in "Advanced Features" gives the
>>> > (IME always wrong) impression that they're optional.
>>> 
>>> They *are* optional.
>>
>> I disagree.
>>
>>> The first chapter is about getting the data in and out.  That is
>>> not optional for using a database.  Transactions, views, foreign
>>> keys, primary keys even, and everything else that some people
>>> think is essential for a "real" database are in fact optional.
>>> Remember that the tutorial is intended for people starting from
>>> zero.
>>
>> No, they're not optional.  If people see how it's done right,
>> starting from zero, they will not then develop bad habits that have
>> to be un-learned.
>>
>>> Let's not overwhelm them right away.
>>
>> I don't think this will be overwhelming.
> 
> When some Pointy-Haired Type has some ridiculously large list of
> things that they say are all "top priorities," that implies that all
> are of equally _LOW_ priority.

Good point.  How about this, then?  For the table create scripts at
the beginning, I'll put in FK's with a pointer to the DB design
section, and just go with 'em from there.  That way, people get used
to seeing and doing things the right way, even if they don't
understand them right off the bat.

> I rather like Tom Lane's suggestion that it makes sense to split into
> _three_ sections:
> 
> 1.  Rudimentary queries, where novices figure out the basics of
> SELECT, INSERT, DELETE, UPDATE.  Perhaps with simple joins.
> 
> 2.  Intermediate queries, where more complex joins, views,
> transactions, subselects, some mention of vacuum/analyze/explain
> and such, are presented.
> 
> 3.  The "advanced" part might instead get called "Designing
> Databases," and present foreign keys, stored procedures,
> triggers, and such.

> Foreign keys would _naturally_ flow into the section that is on
> design, as they are a "design" matter.

Excellent :)

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778

Liberty is inseparable from social justice, and those who dissociate
them, sacrificing the first with the purpose of attaining the second
more quickly, are the true barbarians of our time.
  Mario Vargas Llosa

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [DOCS] German FAQ update

[Bruce Momjian]

Patch applied.  Thanks.

---


Ian Barwick wrote:
> attached.
> 
> Ian Barwick
> [EMAIL PROTECTED]

[ Attachment, skipping... ]

> 
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [DOCS] The Tutorial(TM)

[Christopher Browne]

Oops! [EMAIL PROTECTED] (David Fetter) was seen spray-painting on a wall:
> On Thu, Jan 08, 2004 at 06:07:13PM +0100, Peter Eisentraut wrote:
>> David Fetter wrote:
>> > Expanding on that, putting FK's in "Advanced Features" gives the
>> > (IME always wrong) impression that they're optional.
>> 
>> They *are* optional.
>
> I disagree.
>
>> The first chapter is about getting the data in and out.  That is not
>> optional for using a database.  Transactions, views, foreign keys,
>> primary keys even, and everything else that some people think is
>> essential for a "real" database are in fact optional.
>> Remember that the tutorial is intended for people starting from
>> zero.
>
> No, they're not optional.  If people see how it's done right, starting
> from zero, they will not then develop bad habits that have to be
> un-learned.
>
>> Let's not overwhelm them right away.
>
> I don't think this will be overwhelming.

When some Pointy-Haired Type has some ridiculously large list of
things that they say are all "top priorities," that implies that all
are of equally _LOW_ priority.

If it's all treated as being equally important, then it is fair to say
that it's all UNIMPORTANT.

I rather like Tom Lane's suggestion that it makes sense to split into
_three_ sections:

 1.  Rudimentary queries, where novices figure out the basics of
 SELECT, INSERT, DELETE, UPDATE.  Perhaps with simple joins.

 2.  Intermediate queries, where more complex joins, views,
 transactions, subselects, some mention of vacuum/analyze/explain
 and such, are presented.

 3.  The "advanced" part might instead get called "Designing
 Databases," and present foreign keys, stored procedures,
 triggers, and such.

Foreign keys would _naturally_ flow into the section that is on
design, as they are a "design" matter.
-- 
If this was helpful,  rate me
http://www.ntlug.org/~cbbrowne/wp.html
All bleeding stops...eventually.

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [DOCS] The Tutorial(TM)

[Christopher Browne]

Clinging to sanity, [EMAIL PROTECTED] (David Fetter) mumbled into her beard:
> Chris Browne, could you give me a pointer to your patch so we don't
> step on each other's feet?

It was posted on the patches list on 2003-12-29...
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://cbbrowne.com/info/languages.html
It's always darkest just before it gets pitch black.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [DOCS] The Tutorial(TM)

[Christopher Browne]

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Bruce 
Momjian) transmitted:
> David Fetter wrote:
>> Kind people,
>> 
>> I was looking over the Tutorial section, and noticed that Foreign Keys
>> is in the "Advanced" section.  I believe this is a mistake, and would
>> like to patch up the difference.  What files are involved in the
>> source tree apart from doc/src/sgml/query.sgml and
>> doc/src/sgml/query.sgml ?
>> 
>> TIA :)
>
> I think you just move the section and submit a patch.

I submitted a patch on the "advanced" section to the patches list a
bit over a week ago; haven't seen anything flow through yet...
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://cbbrowne.com/info/sap.html
Rules of the Evil Overlord #35. "I  will not grow a goatee. In the old
days they made  you look diabolic. Now they just make  you look like a
disaffected member of Generation X." 

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster