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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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
[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/users-lounge/docs/faq.html
Re: [HACKERS] 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Linux.conf.au 2003 Report
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Linux.conf.au 2003 Report
On Sun, Feb 02, 2003 at 12:49:34PM -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Linux.conf.au 2003 Report
Kurt Roeckx [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Linux.conf.au 2003 Report
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 ) 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 [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 08:13:30PM -0500, Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] 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 :::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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED] Copeland Computer Consulting ---(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: [HACKERS] 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 [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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: [HACKERS] Linux.conf.au 2003 Report
On Thu, 30 Jan 2003, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Linux.conf.au 2003 Report
Steve Crawford [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
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 [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 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 :::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 ---(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: [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 ) 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Linux.conf.au 2003 Report
[ pgsql-advocacy trimmed from cc list; seems off-topic for them ] D'Arcy J.M. Cain [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Linux.conf.au 2003 Report
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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Linux.conf.au 2003 Report
Christopher Kings-Lynne [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Linux.conf.au 2003 Report
Christopher Kings-Lynne [EMAIL PROTECTED] 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
