Re: [HACKERS] TODO list
-*- Tom Lane [EMAIL PROTECTED] [ 2003-12-17 22:46 ]: Andrew Dunstan [EMAIL PROTECTED] writes: case 6 - limit all users' connections regardless of database: limit all all n That's called max_connections. Don't think we need a redundant implementation of same ... Another little nitpick is that I don't like assuming that any and all are never going to be used as database or user names. (I know that pg_hba.conf already uses all this way, and IMHO that was a bogus decision. Something like * would have been less likely to collide.) On an implementation level, where are you thinking of enforcing this? pg_hba.conf would not be very appropriate for the most likely place to put it, which is in backend startup shortly after establishing a PGPROC entry (with the data about numbers of active connections obtained by scanning the PGPROC array for other backends connected to the same database or with the same userid). I think we've thrown away the PostmasterContext long before that, so we couldn't use cached pg_hba.conf data without some redesign of the startup sequence. I'd like to mention that administrators likely to use the this feature would probably like to be able to tune this without having to modify a file -- updating via SQL (= storing this in a system table) would be extremely nice... -- Regards, Tolli [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading the backend's error-message infrastructure
-*- Tom Lane [EMAIL PROTECTED] [ 2003-03-14 15:33 ]: Darko Prenosil [EMAIL PROTECTED] writes: What about user messages ? If I remember correct, MSSQL had a system catalog table with formated error messages, and it was possible to raise error with error number and it's parameters. It can be very useful when you must raise same error from different places in the code. But that's exactly the direction we are *not* going in. We had that discussion a long time ago when we first started internationalizing our error messages. Peter Eisentraut convinced everybody that we did not want to tie error codes to unique error messages. [digs in archives ...] See for example http://fts.postgresql.org/db/mw/msg.html?mid=1279991 I have no desire to revisit that choice. There is nothing to stop you from creating your own user-defined messages, and even adding them to the .po files in your installation if the need strikes. We aren't going to store them in any system table, however. What about the option of having error numbers unique, but have error numbers linked to error messages (unique in code, but share strings). Just my .02 ISK. -- Regards, Tolli [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL99 ARRAY support proposal
-*- Greg Stark [EMAIL PROTECTED] [ 2003-03-14 17:43 ]: Do you really think someone looking for a function to break up a string into a list of strings would ever think of looking up explode in an index if he hadn't already used PHP or (shudder) VBScript? If one had gotten used to Lotus Notes, sure. ; -- Regards, Tolli [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] psql: Prompt change
Hi mydatabase=# What about making this configurable, so that one could for examble change is prompt to: me:mydatabase@myhost=# Would a patch be accepted if I ever would get around to it? (I won't have time for the next few weeks, so if anyone else wants to do the implementation: feel free :) Regards, Tolli (still confused after issuing commands on the wrong dbhost) -- Tolli [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
-*- Lamar Owen [EMAIL PROTECTED] [ 2002-08-26 15:19 ]: TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by default. I for one thought that it was normal operating procedure to only allow access to trusted machines; maybe I'm odd in that regard. Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it with connection requests. But, if we can thwart this, all the better. Well, ISP's that offer webhosting and database connectivity might also be running a PostgreSQL server that only allows connections from that specific webserver (TCP port 5432 access not blocked as well as an pg_hba.conf entry). Now, if a user with access to the webserver has privileges to open a socket connection, he could exploit this. -- Regards, Tolli [EMAIL PROTECTED] ---(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] Remove implicit unique index creation on SERIAL columns?
Hi -*- Joe Conway [EMAIL PROTECTED] [ 2002-08-18 06:36 ]: Maybe I should restate my comment above: SERIAL should give me a column that automatically increments -- no more, no less -- and it should not allow me to override the value that it gives. Hence an implicit NOT NULL, but also an implicit rejection of a manual insert/update of that field (how hard would this be to do?). I know this causes problems for dumped and reloaded data. In MSSQL this is gotten around by allowing the properties of the data type to be altered, e.g. in MSSQL you can turn the IDENTITY property on or off (in fact, I just checked and MSSQL won't allow you to turn on IDENTITY for a column unless you turn off ALLOW NULLS). You can also specify an exception to the rule when running BCP (the bulk loader command line program). The reason I think this behavior is good, is that it helps prevent toe loss from stray bullets. E.g. you manually add a row where you've specified some value that has not yet been reached by the sequence -- then when someday the sequence reaches said value, your insert fails on a duplicate primary key insertion attempt. If you really need to be able to insert or update a field with an explicit value *sometimes* (and you really know what you're doing), then use a plain sequence and a default, not a SERIAL. I like the functionality you are suggesting. However, when I started thinking about what size this field should be, the idea of keeping the current SERIAL data type and having a SERIAL flag (CREATE TABLE foo (id int serial))... so it's pretty much the same as a seqence, but enforced so that you can't tamper with it. The best part about this is obviously that it doesn't change behaviour of the old SERIAL. Am I right about this, or am I missing something here? -- Regards, Tolli [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
