Linux.conf.au Report
--------------------

The Linux.conf.au is an international Linux/Open Source event that attracts
lots of international speakers.  Total conf attendance was around 360, maybe
even 400 I think.

Gavin Sherry was speaking at this particular conf, and I attended as a
hobbyist.

PostgreSQL got a reasonable amount of attention, particularly since there
were no representatives from other database products there.

Some pics of our PostgreSQL BOF and the Perth Bell Tower:
http://www.zip.com.au/~swm/lca2003
(Gavin is the beardy looking dude 3rd from the left :)  I'm taking the
photo.)

These are the main questions we where asked, or features that were
requested:

* Replication, replication, replication!

- We told them that there are a few solutions, none of them are particularly
great.  Gavin got all sorts of ideas about log shipping.

* IPV6 data types

- Apparently there are some ISPs in some countries that have started to bill
people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
them.

* Collisions in auto-generated names.

- The standard table modification tactic (that I also use) or renaming table
to *_old and creating new one breaks because the primary key of the new
table is assigned the same name as the PK of the old, causing CREATE TABLE
to fail.  This is really annoying.  I think that auto-generated names should
never collide.

* Problem:  person has large database with 4 or 5 humungous tables that they
aren't interested in backing up.  However, they want to back up the rest.

- I suggested that if pg_dump could dump individual schemas, then they could
move their 'don't backup' tables to another schema, and just dump the other
one.

We found out all sorts of interesting places that PostgreSQL is being used:
a large Australian Telco, several restaurants in the Perth area, the Debian
inventory system and the Katie revision control system.  It is also being
evaluated for process control analysis at a steel plant.  Maybe we should
chase some people for case studies?

Chris Kings-Lynne


Thu, 30 Jan 2003 10:49:25 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Linux.conf.au 2003 Report
On Wed, 2003-01-29 at 21:49, Christopher Kings-Lynne wrote:
> * IPV6 data types

Looks like this will be in 7.4, in one form or another.

> - The standard table modification tactic (that I also use) or renaming table
> to *_old and creating new one breaks because the primary key of the new
> table is assigned the same name as the PK of the old, causing CREATE TABLE
> to fail.  This is really annoying.  I think that auto-generated names should
> never collide.

Can this be accomplished without making auto-generated names ugly? And
if not, is it worth the trade-off?

> - I suggested that if pg_dump could dump individual schemas, then they could
> move their 'don't backup' tables to another schema, and just dump the other
> one.

FYI, I submitted a patch for this a couple weeks ago (although it hasn't
been applied yet...) -- it should be in 7.4

Cheers,

Neil
-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




29 Jan 2003 21:57:51 -0500
Neil Conway <neilc@samurai.com>
Re: Linux.conf.au 2003 Report
Christopher Kings-Lynne wrote:
<snip>
> We found out all sorts of interesting places that PostgreSQL is being used:
> a large Australian Telco, several restaurants in the Perth area, the Debian
> inventory system and the Katie revision control system.  It is also being
> evaluated for process control analysis at a steel plant.  Maybe we should
> chase some people for case studies?

Definitely.  Forgot to mention this before, but my gf (Carol Ioanni 
<cioanni@digitaldistribution.com>) is taking the next couple of weeks to 
assist us pretty much "full time" as thankfully she has some spare time 
on her hands for a bit.  :)

She's been pointed towards our urgent need for Case Studies and has 
already begun working with a couple of places to assist them in getting 
them done.  We have a "standard waiver" that places need to sign so 
we're legally in the clear, and a *very* professionally created Case 
Study Worksheet (donated by Sales.Org for the use of all Free / Open 
Source Software projects) that places work through and which gives us a 
very presentable result.

Carol should be a real expert at making Case Studies pretty soon now is 
my guess, as that's all she's going to be doing.  ;-)

If people could ask the places they have contact with, and whom are 
using PostgreSQL in significant ways, if they'd be happy to be a 
reference PostgreSQL Case Study, that would be great.  Some places might 
ask what's in it for them (it's been happening now and again), and 
pretty much we can tangibly say they'll be included in the PostgreSQL 
Advocacy and Marketing site's "Case Studies" section, and we'll be 
making downloadable PDF's of the Case Studies as well so that people can 
distribute them as needed (i.e. to their CIOs/CEOs/CTOs/etc).

For all places that are happy to get involved in this way, please email 
Carol directly and bring her into the conversation so that we can get 
them using the same Case Study Worksheet, get the waiver signed, and 
start grouping and placing the Case Studies appropriately in the Case 
Studies section.

For further background info, the present page views per day of the 
Advocacy and Marketing site from when the new PostgreSQL portal page 
went live (broken into week long groupings) are:

  5/Jan/03: 2203: +++++++++++++++
  6/Jan/03: 3983: +++++++++++++++++++++++++++
  7/Jan/03: 4493: ++++++++++++++++++++++++++++++
  8/Jan/03: 4889: +++++++++++++++++++++++++++++++++
  9/Jan/03: 4364: ++++++++++++++++++++++++++++++
10/Jan/03: 3513: ++++++++++++++++++++++++
11/Jan/03: 2112: +++++++++++++++

12/Jan/03: 2735: +++++++++++++++++++
13/Jan/03: 4405: ++++++++++++++++++++++++++++++
14/Jan/03: 4226: +++++++++++++++++++++++++++++
15/Jan/03: 3752: ++++++++++++++++++++++++++
16/Jan/03: 3467: ++++++++++++++++++++++++
17/Jan/03: 3808: ++++++++++++++++++++++++++
18/Jan/03: 1932: +++++++++++++

19/Jan/03: 1777: ++++++++++++
20/Jan/03: 3641: +++++++++++++++++++++++++
21/Jan/03: 4025: +++++++++++++++++++++++++++
22/Jan/03: 3643: +++++++++++++++++++++++++
23/Jan/03: 3310: +++++++++++++++++++++++
24/Jan/03: 4242: +++++++++++++++++++++++++++++
25/Jan/03: 2749: +++++++++++++++++++

26/Jan/03: 2834: +++++++++++++++++++
27/Jan/03: 4010: +++++++++++++++++++++++++++
28/Jan/03: 4081: ++++++++++++++++++++++++++++

Not huge, but not bad for the first version of the site either.  Since 
the Advocacy and Marketing site isn't very large, it means the case 
studies added there generally do get looked at.

Regards and best wishes,

Justin Clift

> Chris Kings-Lynne

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Thu, 30 Jan 2003 14:22:46 +1030
Justin Clift <justin@postgresql.org>
Re: Linux.conf.au 2003 Report
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Linux.conf.au Report
> [ much snipped ]

> * IPV6 data types
> - Apparently there are some ISPs in some countries that have started to bill
> people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
> them.

Yeah.  This is a pretty self-contained problem, it just needs someone
who's motivated to work on it.  Mostly what we need is to understand how
we want to extend the previously-agreed-to I/O behaviors for IPv4 inet
and cidr types into the v6 domain.  (Or should we back up and ask if the
inet/cidr division still makes sense in the v6 world?  I hope so, but
if not we should face up to it...)

> ...  Maybe we should
> chase some people for case studies?

U betcha ... we were just getting pestered for more of those ...

			regards, tom lane

Thu, 30 Jan 2003 00:55:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Linux.conf.au 2003 Report 
> Yeah.  This is a pretty self-contained problem, it just needs someone
> who's motivated to work on it.  Mostly what we need is to understand how
> we want to extend the previously-agreed-to I/O behaviors for IPv4 inet
> and cidr types into the v6 domain.  (Or should we back up and ask if the
> inet/cidr division still makes sense in the v6 world?  I hope so, but
> if not we should face up to it...)

Maybe we should create a new type 'inet6'???

Chris


Thu, 30 Jan 2003 14:01:37 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: [HACKERS] Linux.conf.au 2003 Report 
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Maybe we should create a new type 'inet6'???

I'd lean towards allowing the existing inet and cidr types to store both
v4 and v6 addresses, if at all possible.  Is there a good motivation for
doing otherwise?

			regards, tom lane

Thu, 30 Jan 2003 01:04:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Linux.conf.au 2003 Report 
On Thu, 30 Jan 2003, Tom Lane wrote:

> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > Maybe we should create a new type 'inet6'???
> 
> I'd lean towards allowing the existing inet and cidr types to store both
> v4 and v6 addresses, if at all possible.  Is there a good motivation for
> doing otherwise?

Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra
96 bits of storage?). Use of ipv4 and ipv6 should be mutually
exclusive. Extra code in inet type causing bloat.

> 
> 			regards, tom lane

Gavin



Thu, 30 Jan 2003 23:42:13 +1100 (EST)
Gavin Sherry <swm@linuxworld.com.au>
Re: [HACKERS] Linux.conf.au 2003 Report 
On Thursday 30 January 2003 07:42, Gavin Sherry wrote:
> Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra
> 96 bits of storage?). Use of ipv4 and ipv6 should be mutually
> exclusive. Extra code in inet type causing bloat.

The inet code has been designed from day one to handle ipv6.  It was assumed 
that the extra glue would be added when it was needed.  I don't see any 
reason to change that.  I also don't think it adds an extra 12 bytes to ipv4 
addresses if you do.  The type is variable size if I recall correctly.

Certainly we don't want people to have two different fields for the same piece 
of information, an IP address.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Thu, 30 Jan 2003 07:53:51 -0500
"D'Arcy J.M. Cain" <darcy@druid.net>
Re: [HACKERS] Linux.conf.au 2003 Report
[ pgsql-advocacy trimmed from cc list; seems off-topic for them ]

"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> On Thursday 30 January 2003 07:42, Gavin Sherry wrote:
>> Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra
>> 96 bits of storage?). Use of ipv4 and ipv6 should be mutually
>> exclusive. Extra code in inet type causing bloat.

> The inet code has been designed from day one to handle ipv6.  It was assumed 
> that the extra glue would be added when it was needed.  I don't see any 
> reason to change that.  I also don't think it adds an extra 12 bytes to ipv4 
> addresses if you do.  The type is variable size if I recall correctly.

Yes, it is; so the "extra storage" argument holds no water.  And the
"code bloat" argument doesn't either, that I can see.  It's not going to
take more code to incorporate ipv6 functionality as part of an existing
datatype than as part of a new datatype.  (If anything, it should take
less code that way; you don't need any extra per-datatype overhead.)

> Certainly we don't want people to have two different fields for the
> same piece of information, an IP address.

That's the main argument in my mind.  If a user *wants* to segregate
ipv4 and v6 addresses, he can do so in any case --- but if he'd rather
have a column that could be either kind, only the unified-datatype
approach will be convenient for him.

Why exactly should "use of ipv4 and ipv6 be mutually exclusive"?
I don't see the argument for that.  (It'd have to be an argument that
doesn't just establish a scenario where you'd want that, but proves
that we should force that point of view upon every application using
IP addresses.)

			regards, tom lane

Thu, 30 Jan 2003 09:48:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Linux.conf.au 2003 Report 
What about cases where I only want one or the other? Would a simple method 
exist to limit input to v4 or v6 only?

Also, what are the implications to functions such as network_sub, 
network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the 
two are freely mixed in the same data type?

Cheers,
Steve

On Wednesday 29 January 2003 10:04 pm, Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> > Maybe we should create a new type 'inet6'???
>
> I'd lean towards allowing the existing inet and cidr types to store both
> v4 and v6 addresses, if at all possible.  Is there a good motivation for
> doing otherwise?
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

Thu, 30 Jan 2003 08:22:05 -0800
Steve Crawford <scrawford@pinpointresearch.com>
Re: [HACKERS] Linux.conf.au 2003 Report
Steve Crawford <scrawford@pinpointresearch.com> writes:
> What about cases where I only want one or the other? Would a simple method 
> exist to limit input to v4 or v6 only?

I would assume we'd add a test function like is_v6(inet).  Given that,
you could add a check constraint "is_v6(col)" or "NOT is_v6(col)" to
any column that you want to restrict.

> Also, what are the implications to functions such as network_sub, 
> network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the
> two are freely mixed in the same data type?

We have to work out what the semantics should be.  I don't know anything
about v6, but I'd imagine v4 addresses form a defined subset of the v6
address space ... if so the semantics seem pretty straightforward.

			regards, tom lane

Thu, 30 Jan 2003 11:28:41 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Linux.conf.au 2003 Report 
On Thu, Jan 30, 2003 at 09:48:37AM -0500, Tom Lane wrote:

> I don't see the argument for that.  (It'd have to be an argument that
> doesn't just establish a scenario where you'd want that, but proves
> that we should force that point of view upon every application using
> IP addresses.)

Given that IPv6 is supposed to allow co-operation with IPv4, it seems
it'd be pretty hard to force such a view on every application using
IP addresses.  DNS, for instance.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Thu, 30 Jan 2003 14:20:07 -0500
Andrew Sullivan <andrew@libertyrms.info>
Re: Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
> 
> > Also, what are the implications to functions such as network_sub, 
> > network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the
> > two are freely mixed in the same data type?
> 
> We have to work out what the semantics should be.  I don't know anything
> about v6, but I'd imagine v4 addresses form a defined subset of the v6
> address space ... if so the semantics seem pretty straightforward.

You have a "ipv4 mapped ipv6 address".  The ipv4 address 1.2.3.4 becomes
::ffff:1.2.3.4.  But I'm not really in favour of automatically
changing an ipv4 address to an ipv6 address.  And you really
shouldn't return an ipv4 address as an ipv6 address.

Some thing you also shouldn't forget for ipv6 addresses is the
scope.  An address with a scope of the link can be assigned to
several interfaces.  If they want to differentiate between them,
should they be able to store it the same field, or use a
different one?

My question really is how you're going to store it.  Are you
going to store is as a character string, or as binary?
If you store is as binary, how will you know if it's an ipv4 or
ipv6 address?  Based on the size?

 From an application point of view it's more handy if you have a
combination of the address family and the data, so they don't
have to guess all the time.


P.S.: I don't really like the ipv6 patch.  It's more complicated
than it should be.  I really don't have the time to fix it/do it
better though.


Kurt


Thu, 30 Jan 2003 20:59:59 +0100
Kurt Roeckx <Q@ping.be>
Re: [HACKERS] Linux.conf.au 2003 Report
Kurt Roeckx <Q@ping.be> writes:
> On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
>> We have to work out what the semantics should be.  I don't know anything
>> about v6, but I'd imagine v4 addresses form a defined subset of the v6
>> address space ... if so the semantics seem pretty straightforward.

> You have a "ipv4 mapped ipv6 address".  The ipv4 address 1.2.3.4 becomes
> ::ffff:1.2.3.4.  But I'm not really in favour of automatically
> changing an ipv4 address to an ipv6 address.  And you really
> shouldn't return an ipv4 address as an ipv6 address.

No, we should keep the distinction for purposes of storage and display.
The question was about what the semantics should be when comparing v4
and v6 addresses in operations like network_sub.  It seems perfectly
reasonable to convert the v4 address to the mapped v6 equivalent and then
do a v6 comparison in that situation.  Do we have any operators where
this would not be a sensible definition?

> My question really is how you're going to store it.  Are you
> going to store is as a character string, or as binary?

Binary, same as we do now for v4.

> If you store is as binary, how will you know if it's an ipv4 or
> ipv6 address?  Based on the size?

Why not?

			regards, tom lane

Thu, 30 Jan 2003 20:13:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Linux.conf.au 2003 Report 
On Thu, 30 Jan 2003, Andrew Sullivan wrote:

> Given that IPv6 is supposed to allow co-operation with IPv4, it seems
> it'd be pretty hard to force such a view on every application using
> IP addresses.  DNS, for instance.

Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
record types ("A" versus "AAAA") in the DNS "database".

And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
if you're talking about the compatability addresses. I won't get into
all the reasons why.

All that said, I'm not advocating separating (or not separating)
IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see
situations where I might want to store both together, but then again, I
can see situations where I certainly wouldn't.

Perhaps we should think about another example to try to illuminate this:
what about storing ISO/OSI addresses in the same type as well? Isn't
that just the same thing as storing IPv4 and IPv6 addresses together?

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Fri, 31 Jan 2003 10:57:17 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: Linux.conf.au 2003 Report
On Thu, 30 Jan 2003, Tom Lane wrote:

> I don't know anything
> about v6, but I'd imagine v4 addresses form a defined subset of the v6
> address space ...

No, they do not. The address spaces are completely independent. (There
is a "compatability space" for IPv4 addresses, but it turned out to be
impractical, and thus is generally not used. Certainly you cannot route
to arbitrary v4 hosts using a v6 address.)

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Fri, 31 Jan 2003 10:58:48 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: [HACKERS] Linux.conf.au 2003 Report 
On Thu, 2003-01-30 at 19:57, Curt Sampson wrote:
> On Thu, 30 Jan 2003, Andrew Sullivan wrote:
> 
> > Given that IPv6 is supposed to allow co-operation with IPv4, it seems
> > it'd be pretty hard to force such a view on every application using
> > IP addresses.  DNS, for instance.
> 
> Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
> record types ("A" versus "AAAA") in the DNS "database".
> 
> And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
> if you're talking about the compatability addresses. I won't get into
> all the reasons why.
> 
> All that said, I'm not advocating separating (or not separating)
> IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see
> situations where I might want to store both together, but then again, I
> can see situations where I certainly wouldn't.
> 
> Perhaps we should think about another example to try to illuminate this:
> what about storing ISO/OSI addresses in the same type as well? Isn't
> that just the same thing as storing IPv4 and IPv6 addresses together?
> 
> cjs


That's because IPv6 is a completely new and different protocol from
IPv4.  It has new address requirements and is completely distinct from
IPv4.  For some reason, people can't wait to lump the two together. 
Make no mistake about it, IPv4 and IPv6 share pretty much a name and
that's about it.

IPv6 has some provisions to help people migrate toward it (from IPv4),
however, IPv6 is a distinctly different protocol.  It doesn't help the
confusion that many OS's try to confuse programmers by exposing a single
socket interface, etc.  Simple fact remains, IPv6 is not IPv4.

Wish more people would remember this.


...sorry...that's my rant for today...  ;)


Regards,

	Greg


-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting


30 Jan 2003 20:21:09 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 10:57:17AM +0900, Curt Sampson wrote:
> Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
> record types ("A" versus "AAAA") in the DNS "database".
> 
> And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
> if you're talking about the compatability addresses. I won't get into
> all the reasons why.

I know it's not happening.  On the other hand, IPv6 isn't happening
terribly much, either.

Soon, the NAT + CIDR bag-on-the-side will run out of room, and people
will have no choice but to use IPv6.  But the pain of making them
interoperate is part of the cause of resistance.  The compatibility
addresses are going to _have_ to work if people are really going to
move, unless someone is contemplating another great TCP/IP cutover
day.  (And that didn't even work last time, when several networks
just dropped right off the proto-Net for a while.) So it seems to me
that the compatibility addresses are going to need to be supported by
any IPv6-aware system.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Fri, 31 Jan 2003 09:13:18 -0500
Andrew Sullivan <andrew@libertyrms.info>
Re: Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 08:13:30PM -0500, Tom Lane wrote:
> Kurt Roeckx <Q@ping.be> writes:
> > On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
> >> We have to work out what the semantics should be.  I don't know anything
> >> about v6, but I'd imagine v4 addresses form a defined subset of the v6
> >> address space ... if so the semantics seem pretty straightforward.
> 
> > You have a "ipv4 mapped ipv6 address".  The ipv4 address 1.2.3.4 becomes
> > ::ffff:1.2.3.4.  But I'm not really in favour of automatically
> > changing an ipv4 address to an ipv6 address.  And you really
> > shouldn't return an ipv4 address as an ipv6 address.
> 
> No, we should keep the distinction for purposes of storage and display.
> The question was about what the semantics should be when comparing v4
> and v6 addresses in operations like network_sub.  It seems perfectly
> reasonable to convert the v4 address to the mapped v6 equivalent and then
> do a v6 comparison in that situation.  Do we have any operators where
> this would not be a sensible definition?

broadcast() doesn't make sense for ipv6.  There is no such thing.
network() might be useful, but mean something a little bit
different.

Ipv6 calls the mask length the prefix length ...

abbrev() might also need some tweaking, specially in combination
with the compressed format.  Not sure if abbrev() is really
useful.

There seems to be no documentation on network_sub, but I assume
it's the same as "<<".  It shouldn't be a problem converting it
to the ipv6 address, and adding 96 to the mask.


Kurt


Fri, 31 Jan 2003 19:42:33 +0100
Kurt Roeckx <Q@ping.be>
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote:
> 
> IPv6 has some provisions to help people migrate toward it (from IPv4),
> however, IPv6 is a distinctly different protocol.

The ipv4 mapped ipv6 addresses are to help migrate, but it
actually makes things worse.  If this wouldn't be the case, some
software wouldn't look as ugly as it does now.

Then there is the "problem" that BSD no longer really supports
the ipv4 mapped ipv6 addresses.  It will refuse to use such an
address on an AF_INET6 socket, while that (still) works on other
OSs.  The badly ported software will not work on them.

> It doesn't help the
> confusion that many OS's try to confuse programmers by exposing a single
> socket interface, etc.  Simple fact remains, IPv6 is not IPv4.

It's a good things that the socket interface can actually work
with all protocol!  It doesn't only work with AF_INET, but also
AF_UNIX, and probably others.  It's a good things that things
like socket(), bind(), connect() don't need to be replaced by
other things.

The new protocol independed API for translation between
host name and address, in both text and binary representation is
also a good thing.

The struct addrinfo is really useful, since you can store all
info you need in it for all calls to the socket API.  The ipv6
patch really should make better use of it, both if you have and
don't have ipv6 support, and get rid of most of those #ifdefs.


Kurt


Fri, 31 Jan 2003 20:04:46 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 09:13:18AM -0500, Andrew Sullivan wrote:
> 
> Soon, the NAT + CIDR bag-on-the-side will run out of room, and people
> will have no choice but to use IPv6.  But the pain of making them
> interoperate is part of the cause of resistance.  The compatibility
> addresses are going to _have_ to work if people are really going to
> move, unless someone is contemplating another great TCP/IP cutover
> day.

What do you mean with "compatibility addresses"?  I don't know of
any such thing.

The ipv4 mapped ipv6 address is just a "hack" on the local
system.  You never see those "on the wire".

Anyway, what is the problem?  ipv4 and ipv6 can happely live on
the same network, it does so far a long time now.  Host just
support both ipv4 and ipv6 now.  If an application is written
properly, you shouldn't even notice the connection is over ipv4
or ipv6.


Kurt


Fri, 31 Jan 2003 20:21:21 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
On Fri, 2003-01-31 at 13:04, Kurt Roeckx wrote:
> On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote:
> > It doesn't help the
> > confusion that many OS's try to confuse programmers by exposing a single
> > socket interface, etc.  Simple fact remains, IPv6 is not IPv4.
> 
> It's a good things that the socket interface can actually work
> with all protocol!  It doesn't only work with AF_INET, but also
> AF_UNIX, and probably others.  It's a good things that things
> like socket(), bind(), connect() don't need to be replaced by
> other things.


That's actually not what I was talking about.  Please see the recent
IPv6 support thread as an example.  The fact that an OS allows IPv4
connections to be completed even though you explicitly requested IPv6
protocol, only adds to much confusion (one of many such oddities which
some OS's allow).  Heck, along those lines, they should allow NCP
connections to come through too.  Or, how about UDP traffic on TCP
sockets.  If I wanted IPv4 traffic, I'll ask for it.  Likewise of IPv6.

My point being, too many people are in a hurry to confuse/combine the
two when they are very clearly two distinct protocols, each having
distinct needs.  The faster people treat them as such, the quicker
things will become better for everyone.

The fact that some OS's attempt to blur the API lines and underlying
semantics between the two protocols only further confuses things as it
falsely leads people to believe that they are more or less the same
protocol.


Regards,

-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting


31 Jan 2003 13:37:08 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 08:21:21PM +0100, Kurt Roeckx wrote:
> What do you mean with "compatibility addresses"?  I don't know of
> any such thing.

I'm thinking of these sorts of things (my faviourite description,
from RFC 2893):

IPv6/IPv4 nodes that perform automatic tunneling are assigned
IPv4-compatible address.  An IPv4-compatible address is identified by
an all-zeros 96-bit prefix, and holds an IPv4 address in the
low-order 32-bits.  IPv4-compatible addresses are structured as
follows:

          |              96-bits                 |   32-bits    |
          +--------------------------------------+--------------+
          |            0:0:0:0:0:0               | IPv4 Address |
          +--------------------------------------+--------------+
                       IPv4-Compatible IPv6 Address Format

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Fri, 31 Jan 2003 18:51:49 -0500
Andrew Sullivan <andrew@libertyrms.info>
Re: Linux.conf.au 2003 Report
On Fri, 31 Jan 2003, Kurt Roeckx wrote:

> It's a good things that the socket interface can actually work
> with all protocol!  It doesn't only work with AF_INET, but also
> AF_UNIX, and probably others.  It's a good things that things
> like socket(), bind(), connect() don't need to be replaced by
> other things.

Sure. But you still want to be able to say (and can say, in some [many?]
socket API implementations) that you want to accept only IPv4 or only IPv6
connections. I also want to be able to say the same thing in my database.

So probably, this means setting up separate types for IPv4 and IPv6
addresses, and a third type to hold both IPv4 and IPv6 addresses. That
third type could also be extended to hold OSI, NS, and whatever other
type of addresses people feel would be useful.

I suppose another way of implementing this would be to set up some easy
way to put a constraint on a column such that you could constrain it to
hold only IPv4 or IPv6 addresses.

And I would be interested to hear the opinions of those who want to put
IPv4 and IPv6 addresses in the same type as to whether you do or do not
support also putting ISO/OSI and Novell addresses into that type as well,
and why or why not.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Sat, 1 Feb 2003 14:35:15 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: Linux.conf.au 2003 Report
On Fri, 31 Jan 2003, Andrew Sullivan wrote:

> But the pain of making them
> interoperate is part of the cause of resistance.  The compatibility
> addresses are going to _have_ to work if people are really going to
> move...

There is no pain in this respect; you get your compatability by simply
running both IPv4 and IPv6 on the hosts that interoperate.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Sat, 1 Feb 2003 15:15:52 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 06:51:49PM -0500, Andrew Sullivan wrote:
> On Fri, Jan 31, 2003 at 08:21:21PM +0100, Kurt Roeckx wrote:
> > What do you mean with "compatibility addresses"?  I don't know of
> > any such thing.
> 
>           |              96-bits                 |   32-bits    |
>           +--------------------------------------+--------------+
>           |            0:0:0:0:0:0               | IPv4 Address |
>           +--------------------------------------+--------------+
>                        IPv4-Compatible IPv6 Address Format

Oh, those.  I forgot about them.

I've never seen anybody using them, and I can't think of a good
reason to use them either.  They're not even routable now.


Kurt


Sat, 1 Feb 2003 13:36:01 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> 
> Sure. But you still want to be able to say (and can say, in some [many?]
> socket API implementations) that you want to accept only IPv4 or only IPv6
> connections. I also want to be able to say the same thing in my database.

You just create either an ipv4 or ipv6 socket.  And then you can
bind to an address of that type if you want.  Either all
addresses or a specific one.

Depending on the OS, binding to all addresses on IPv6 will also
bind to all the ipv4 addresses, which can be both handy an
annoying.  On others you need 2 sockets if you want to listen on
both ipv4 and ipv6, which makes more sense.


Kurt


Sun, 2 Feb 2003 13:38:36 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
Kurt Roeckx wrote:
> On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> > 
> > Sure. But you still want to be able to say (and can say, in some [many?]
> > socket API implementations) that you want to accept only IPv4 or only IPv6
> > connections. I also want to be able to say the same thing in my database.
> 
> You just create either an ipv4 or ipv6 socket.  And then you can
> bind to an address of that type if you want.  Either all
> addresses or a specific one.
> 
> Depending on the OS, binding to all addresses on IPv6 will also
> bind to all the ipv4 addresses, which can be both handy an
> annoying.  On others you need 2 sockets if you want to listen on
> both ipv4 and ipv6, which makes more sense.

Well, that's interesting.  Current CVS only binds to IPv6, and assumes
IPv4 will work too.  If some OS's require a separate Ipv4 binding, we
are going to hear about it before 7.4:

---------------------------------------------------------------------------


#ifdef HAVE_IPV6
        /* Try INET6 first.  May fail if kernel doesn't support IP6 */
        status = StreamServerPort(AF_INET6, VirtualHost,
                                  (unsigned short) PostPortNumber,
                                  UnixSocketDir,
                                  &ServerSock_INET);
        if (status != STATUS_OK)
        {
            elog(LOG, "IPv6 support disabled --- perhaps the kernel does not support IPv6");
#endif
            status = StreamServerPort(AF_INET, VirtualHost,
                                      (unsigned short) PostPortNumber,
                                      UnixSocketDir,
                                      &ServerSock_INET);
            if (status != STATUS_OK)
            {
                postmaster_error("cannot create INET stream port");
                ExitPostmaster(1);
            }
#ifdef HAVE_IPV6
            else
                elog(LOG, "IPv4 socket created");
        }
#endif
    }


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

Sun, 2 Feb 2003 08:19:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Linux.conf.au 2003 Report
On Sun, Feb 02, 2003 at 08:19:23AM -0500, Bruce Momjian wrote:
> Kurt Roeckx wrote:
> > Depending on the OS, binding to all addresses on IPv6 will also
> > bind to all the ipv4 addresses, which can be both handy an
> > annoying.  On others you need 2 sockets if you want to listen on
> > both ipv4 and ipv6, which makes more sense.
> 
> Well, that's interesting.  Current CVS only binds to IPv6, and assumes
> IPv4 will work too.  If some OS's require a separate Ipv4 binding, we
> are going to hear about it before 7.4:

It will not work on atleast OpenBSD.  I believe it won't work on
the other BSDs in the future either.


Kurt


Sun, 2 Feb 2003 14:26:59 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
On Sun, 2 Feb 2003, Bruce Momjian wrote:

> Kurt Roeckx wrote:
> > On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> > > 
> > > Sure. But you still want to be able to say (and can say, in some [many?]
> > > socket API implementations) that you want to accept only IPv4 or only IPv6
> > > connections. I also want to be able to say the same thing in my database.
> > 
> > You just create either an ipv4 or ipv6 socket.  And then you can
> > bind to an address of that type if you want.  Either all
> > addresses or a specific one.
> > 
> > Depending on the OS, binding to all addresses on IPv6 will also
> > bind to all the ipv4 addresses, which can be both handy an
> > annoying.  On others you need 2 sockets if you want to listen on
> > both ipv4 and ipv6, which makes more sense.
> 
> Well, that's interesting.  Current CVS only binds to IPv6, and assumes
> IPv4 will work too.  If some OS's require a separate Ipv4 binding, we
> are going to hear about it before 7.4:

I don't think we should listen on IPv6 just because it is supported. It
should be a configuration variable:

tcpip_socket = true
ipv6 = true

Gavin



Mon, 3 Feb 2003 00:55:10 +1100 (EST)
Gavin Sherry <swm@linuxworld.com.au>
Re: Linux.conf.au 2003 Report
Gavin Sherry wrote:
> On Sun, 2 Feb 2003, Bruce Momjian wrote:
> 
> > Kurt Roeckx wrote:
> > > On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> > > > 
> > > > Sure. But you still want to be able to say (and can say, in some [many?]
> > > > socket API implementations) that you want to accept only IPv4 or only IPv6
> > > > connections. I also want to be able to say the same thing in my database.
> > > 
> > > You just create either an ipv4 or ipv6 socket.  And then you can
> > > bind to an address of that type if you want.  Either all
> > > addresses or a specific one.
> > > 
> > > Depending on the OS, binding to all addresses on IPv6 will also
> > > bind to all the ipv4 addresses, which can be both handy an
> > > annoying.  On others you need 2 sockets if you want to listen on
> > > both ipv4 and ipv6, which makes more sense.
> > 
> > Well, that's interesting.  Current CVS only binds to IPv6, and assumes
> > IPv4 will work too.  If some OS's require a separate Ipv4 binding, we
> > are going to hear about it before 7.4:
> 
> I don't think we should listen on IPv6 just because it is supported. It
> should be a configuration variable:
> 
> tcpip_socket = true
> ipv6 = true

We had a huge discussion on this.  I think you were away for it.  You
can control what you listen on by modifying pg_hba.conf.


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

Sun, 2 Feb 2003 09:18:05 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Linux.conf.au 2003 Report
On Sun, 2 Feb 2003, Kurt Roeckx wrote:

> On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> >
> > Sure. But you still want to be able to say (and can say, in some [many?]
> > socket API implementations) that you want to accept only IPv4 or only IPv6
> > connections. I also want to be able to say the same thing in my database.
>
> You just create either an ipv4 or ipv6 socket.

Um...I'm talking about inserting data into a column in postgres. How do
I declare that a column can accept IPv4 addresses only?

And why will *nobody* address the question of whether this type should
include ISO/OSI addresses or not, and why?

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Mon, 3 Feb 2003 02:04:57 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: Linux.conf.au 2003 Report
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Gavin Sherry wrote:
>> I don't think we should listen on IPv6 just because it is supported. It
>> should be a configuration variable:
>> 
>> tcpip_socket = true
>> ipv6 = true

> We had a huge discussion on this.  I think you were away for it.  You
> can control what you listen on by modifying pg_hba.conf.

Can you actually control whether the postmaster is listening by
modifying pg_hba.conf?  I don't think so.

I think I was the one who talked us into assuming that ipv4 and ipv6
should be treated as a single protocol.  But some people have since made
pretty good cases that it's better to regard them as separate protocols.
Perhaps we should rethink that decision.

			regards, tom lane

Sun, 02 Feb 2003 12:49:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Linux.conf.au 2003 Report 
On Sun, 2 Feb 2003, Tom Lane wrote:

> I think I was the one who talked us into assuming that ipv4 and ipv6
> should be treated as a single protocol.  But some people have since made
> pretty good cases that it's better to regard them as separate protocols.

 From a security standpoint, I think it's definitely better to regard
them as separate protocols. They are certainly separately filtered on
firewalls, and they are often routed differently, too.

That said, I see no reason not to have some sort of easy way of saying,
"listen on all the interfaces you can find using all the protocols you
know." So long as you have the ability to distinguish where you listen
by both protocol and address, it's easy to be as secure as you need to be.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Mon, 3 Feb 2003 03:51:36 +0900 (JST)
Curt Sampson <cjs@cynic.net>
Re: Linux.conf.au 2003 Report 
On Sun, Feb 02, 2003 at 12:49:34PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Gavin Sherry wrote:
> >> I don't think we should listen on IPv6 just because it is supported. It
> >> should be a configuration variable:
> >> 
> >> tcpip_socket = true
> >> ipv6 = true
> 
> > We had a huge discussion on this.  I think you were away for it.  You
> > can control what you listen on by modifying pg_hba.conf.
> 
> Can you actually control whether the postmaster is listening by
> modifying pg_hba.conf?  I don't think so.

Why isn't virtual_host used for deciding to what addresses it
should listen?

It currently only seems to support 1 address, and I don't really
know why.  Is there a reason you can't make this a list of
hostnames/ip addresses?  It really is where it belongs.


Kurt


Sun, 2 Feb 2003 20:13:40 +0100
Kurt Roeckx <Q@ping.be>
Re: Linux.conf.au 2003 Report
Kurt Roeckx <Q@ping.be> writes:
> [virtual_host] currently only seems to support 1 address, and I don't really
> know why.  Is there a reason you can't make this a list of
> hostnames/ip addresses?

That was what the boys at uu.net needed, so that's what they
implemented.  If you need more, I think a patch would be accepted ...

			regards, tom lane

Sun, 02 Feb 2003 14:23:35 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Linux.conf.au 2003 Report 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Gavin Sherry wrote:
> >> I don't think we should listen on IPv6 just because it is supported. It
> >> should be a configuration variable:
> >> 
> >> tcpip_socket = true
> >> ipv6 = true
> 
> > We had a huge discussion on this.  I think you were away for it.  You
> > can control what you listen on by modifying pg_hba.conf.
> 
> Can you actually control whether the postmaster is listening by
> modifying pg_hba.conf?  I don't think so.

Good question.  I assumed if you removed the IPv6 local address that a
local IPv6 wouldn't work, and that you need to specify an IPv6 remote
host to have it be accepted. Yes, it is still listening on Ipv6, but no
one can get in except localhost by default, so I don't see the issue.

> I think I was the one who talked us into assuming that ipv4 and ipv6
> should be treated as a single protocol.  But some people have since made
> pretty good cases that it's better to regard them as separate protocols.
> Perhaps we should rethink that decision.

Sure.

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

Sun, 2 Feb 2003 19:34:21 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Linux.conf.au 2003 Report

Is Linux.conf.au the event PostgreSQL should use for coverage in
Australia next year?

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:
> Linux.conf.au Report
> --------------------
> 
> The Linux.conf.au is an international Linux/Open Source event that attracts
> lots of international speakers.  Total conf attendance was around 360, maybe
> even 400 I think.
> 
> Gavin Sherry was speaking at this particular conf, and I attended as a
> hobbyist.
> 
> PostgreSQL got a reasonable amount of attention, particularly since there
> were no representatives from other database products there.
> 
> Some pics of our PostgreSQL BOF and the Perth Bell Tower:
> http://www.zip.com.au/~swm/lca2003
> (Gavin is the beardy looking dude 3rd from the left :)  I'm taking the
> photo.)
> 
> These are the main questions we where asked, or features that were
> requested:
> 
> * Replication, replication, replication!
> 
> - We told them that there are a few solutions, none of them are particularly
> great.  Gavin got all sorts of ideas about log shipping.
> 
> * IPV6 data types
> 
> - Apparently there are some ISPs in some countries that have started to bill
> people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
> them.
> 
> * Collisions in auto-generated names.
> 
> - The standard table modification tactic (that I also use) or renaming table
> to *_old and creating new one breaks because the primary key of the new
> table is assigned the same name as the PK of the old, causing CREATE TABLE
> to fail.  This is really annoying.  I think that auto-generated names should
> never collide.
> 
> * Problem:  person has large database with 4 or 5 humungous tables that they
> aren't interested in backing up.  However, they want to back up the rest.
> 
> - I suggested that if pg_dump could dump individual schemas, then they could
> move their 'don't backup' tables to another schema, and just dump the other
> one.
> 
> We found out all sorts of interesting places that PostgreSQL is being used:
> a large Australian Telco, several restaurants in the Perth area, the Debian
> inventory system and the Katie revision control system.  It is also being
> evaluated for process control analysis at a steel plant.  Maybe we should
> chase some people for case studies?
> 
> Chris Kings-Lynne
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

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

Fri, 14 Feb 2003 19:24:12 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Linux.conf.au 2003 Report
I think so - Gavin?  As far as I'm aware there's not really anything else
on the open source circuit.  There is often a MySQL rep there as well
apparently.

Chris

On Fri, 14 Feb 2003, Bruce Momjian wrote:

>
> Is Linux.conf.au the event PostgreSQL should use for coverage in
> Australia next year?
>
> ---------------------------------------------------------------------------
>
> Christopher Kings-Lynne wrote:
> > Linux.conf.au Report
> > --------------------
> >
> > The Linux.conf.au is an international Linux/Open Source event that attracts
> > lots of international speakers.  Total conf attendance was around 360, maybe
> > even 400 I think.
> >
> > Gavin Sherry was speaking at this particular conf, and I attended as a
> > hobbyist.
> >
> > PostgreSQL got a reasonable amount of attention, particularly since there
> > were no representatives from other database products there.
> >
> > Some pics of our PostgreSQL BOF and the Perth Bell Tower:
> > http://www.zip.com.au/~swm/lca2003
> > (Gavin is the beardy looking dude 3rd from the left :)  I'm taking the
> > photo.)
> >
> > These are the main questions we where asked, or features that were
> > requested:
> >
> > * Replication, replication, replication!
> >
> > - We told them that there are a few solutions, none of them are particularly
> > great.  Gavin got all sorts of ideas about log shipping.
> >
> > * IPV6 data types
> >
> > - Apparently there are some ISPs in some countries that have started to bill
> > people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
> > them.
> >
> > * Collisions in auto-generated names.
> >
> > - The standard table modification tactic (that I also use) or renaming table
> > to *_old and creating new one breaks because the primary key of the new
> > table is assigned the same name as the PK of the old, causing CREATE TABLE
> > to fail.  This is really annoying.  I think that auto-generated names should
> > never collide.
> >
> > * Problem:  person has large database with 4 or 5 humungous tables that they
> > aren't interested in backing up.  However, they want to back up the rest.
> >
> > - I suggested that if pg_dump could dump individual schemas, then they could
> > move their 'don't backup' tables to another schema, and just dump the other
> > one.
> >
> > We found out all sorts of interesting places that PostgreSQL is being used:
> > a large Australian Telco, several restaurants in the Perth area, the Debian
> > inventory system and the Katie revision control system.  It is also being
> > evaluated for process control analysis at a steel plant.  Maybe we should
> > chase some people for case studies?
> >
> > Chris Kings-Lynne
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
>


Sat, 15 Feb 2003 22:27:11 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: [HACKERS] Linux.conf.au 2003 Report
On Sat, 15 Feb 2003, Christopher Kings-Lynne wrote:

> I think so - Gavin?  As far as I'm aware there's not really anything else
> on the open source circuit.  There is often a MySQL rep there as well
> apparently.

Chris is right. David Axmark (MySQL AB) usually turns up, but he didn't
this year.

The conference has an attendence of 400 people. The audience is fairly
technical -- getting less so each year though :-(.

If I go next year, I think I will give a tutorial focusing on migrating
MySQL applications to PostgreSQL. Many attendees of my talk this year were
looking for information like that -- something I didn't cover :-\.

Gavin



Sun, 16 Feb 2003 19:50:12 +1100 (EST)
Gavin Sherry <swm@linuxworld.com.au>
Re: [HACKERS] Linux.conf.au 2003 Report