Re: [HACKERS] FE/BE Protocol - Specific version
If my memory serves me well, Oracle has a number of system triggers. On database startup and shutdown and perhaps also on connection start and stop. Sometimes they're very handy. Is this a TODO? Is there an API that would make sense for us? I believe it would make sense. But I'm not up to the task to implement it. Maybe if someone is looking into triggers anyway in another context... -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] FE/BE Protocol - Specific version
Kaare Rasmussen wrote: It would be nice if we could configure a function to run on connection start. We have the ability to SET values per db or user, but not to If my memory serves me well, Oracle has a number of system triggers. On database startup and shutdown and perhaps also on connection start and stop. Sometimes they're very handy. Is this a TODO? Is there an API that would make sense for us? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FE/BE Protocol - Specific version
It would be nice if we could configure a function to run on connection start. We have the ability to SET values per db or user, but not to If my memory serves me well, Oracle has a number of system triggers. On database startup and shutdown and perhaps also on connection start and stop. Sometimes they're very handy. -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] FE/BE Protocol - Specific version
Bruce Badger wrote: What I'd do, if I wanted to lock out old clients from accessing particular tables, is just rename the tables to something else. (Or keep using the same names, but put the tables in a schema or database that old clients won't look in.) The clients wouldn't fail very gracefully, perhaps, but the protocol-level hack doesn't qualify as graceful in my book either ... I don't think that there is a graceful way to fix this. Unless I can pull off the blocking old protocol versions trick, it seems that the most likely option will come from another chance coincidence, i.e. that the StORE schema changes. It would be nice if we could configure a function to run on connection start. We have the ability to SET values per db or user, but not to execute a function. The function could test SELECT version() and send a message to the user. -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] FE/BE Protocol - Specific version
Will it be possible to tell a PostgreSQL back end to use *only* the new version of the FE/BE protocol? That is, will it be possible to set up a database that will reject connection attempts that do not use the new protocol version? Thanks, Bruce signature.asc Description: This is a digitally signed message part
Re: [HACKERS] FE/BE Protocol - Specific version
Bruce Badger [EMAIL PROTECTED] writes: Will it be possible to tell a PostgreSQL back end to use *only* the new version of the FE/BE protocol? That is, will it be possible to set up a database that will reject connection attempts that do not use the new protocol version? I cannot imagine a reason that that would be a good idea ... but convince me if you can ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FE/BE Protocol - Specific version
On Fri, 2003-08-29 at 13:23, Tom Lane wrote: Bruce Badger [EMAIL PROTECTED] writes: Will it be possible to tell a PostgreSQL back end to use *only* the new version of the FE/BE protocol? That is, will it be possible to set up a database that will reject connection attempts that do not use the new protocol version? I cannot imagine a reason that that would be a good idea ... but convince me if you can ... Well, I'm asking because of a specific application. StORE is a version control system for VisualWorks Smalltalk. PostgreSQL is often the chosen back end for StORE. There are many publicly accessible StORE repositories running on PostgreSQL. The StORE to PostgreSQL mapping code currently encodes Byte arrays using Base64, and stores them in bytea fields. It should not have happened like this, but it did - my fault, a stop-gap got used before the gap was properly filled. I would like to migrate to using escaped byte arrays in a new version of the StORE-PostgreSQL mapping software, but we have to be able to accommodate the mixture of old and new databases, and old and new client libraries. I would prefer to have each StORE database have only one encoding used throughout. So old databases would still use Base64, and new databases would use escaped strings. The new databases will contain an additional table indicating the version of the StORE mapping library they were created by, and this will enable newer implementations to use the correct encoding in any given situation. The old mapping library, of course, will just keep on trying to use the old Base64 encoding. As the new FE/BE protocol is not supported by the old mapping library, we could stop old versions of the library getting confused (and perhaps corrupting) new databases by setting new databases to refuse connections using old FE/BE protocol version. So, being able to stop connections trying to use old protocol versions would be very helpful in this case. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FE/BE Protocol - Specific version
So, being able to stop connections trying to use old protocol versions would be very helpful in this case. Wouldn't it be better to have StORE run a select version() after connecting? Even better would be to call PQprotocolVersion() as it is a protocol issue. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] FE/BE Protocol - Specific version
Rod Taylor [EMAIL PROTECTED] writes: So, being able to stop connections trying to use old protocol versions would be very helpful in this case. Wouldn't it be better to have StORE run a select version() after connecting? Well, his point is that old versions of his client code wouldn't know to do that. However, I don't think that what he's suggesting is a suitable answer either --- he wants to rely on a chance coincidence, namely that we're upgrading the FE/BE protocol at the same time that he wants to make an incompatible application-level change. What I'd do, if I wanted to lock out old clients from accessing particular tables, is just rename the tables to something else. (Or keep using the same names, but put the tables in a schema or database that old clients won't look in.) The clients wouldn't fail very gracefully, perhaps, but the protocol-level hack doesn't qualify as graceful in my book either ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FE/BE Protocol - Specific version
On Fri, 2003-08-29 at 23:35, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: So, being able to stop connections trying to use old protocol versions would be very helpful in this case. Wouldn't it be better to have StORE run a select version() after connecting? Well, his point is that old versions of his client code wouldn't know to do that. However, I don't think that what he's suggesting is a suitable answer either --- he wants to rely on a chance coincidence, namely that we're upgrading the FE/BE protocol at the same time that he wants to make an incompatible application-level change. Exactly right. I made a mistake and this is a chance to fix it. Really, just that simple. What I'd do, if I wanted to lock out old clients from accessing particular tables, is just rename the tables to something else. (Or keep using the same names, but put the tables in a schema or database that old clients won't look in.) The clients wouldn't fail very gracefully, perhaps, but the protocol-level hack doesn't qualify as graceful in my book either ... I don't think that there is a graceful way to fix this. Unless I can pull off the blocking old protocol versions trick, it seems that the most likely option will come from another chance coincidence, i.e. that the StORE schema changes. Unfortunately, I am not in a position to initiate a change in the StORE schema. StORE is also used with other RDBMSs, and the users of those have no incentive to bless a change in the schema just to help out the PostgreSQL users. So, if it did come to pass that rejecting connections on the basis of protocol version was possible, then I could fix the broken encoding implementation. Otherwise, I think I'll have to wait for the next chance coincidence. ... unless anyone has any better ideas? :-/ All the best, Bruce ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FE/BE Protocol - Specific version
On Fri, 2003-08-29 at 23:23, Rod Taylor wrote: So, being able to stop connections trying to use old protocol versions would be very helpful in this case. Wouldn't it be better to have StORE run a select version() after connecting? Even better would be to call PQprotocolVersion() as it is a protocol issue. Well, if we could compel every existing user of StORE + PostrgeSQL to upgrade to a new version of the mapping software, yes. I think that we must accept that one or more people may hang onto old versions of the mapping software which, of course, would not contain the checks you suggest :-( ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] FE/BE Protocol - Specific version
Bruce Badger [EMAIL PROTECTED] writes: Unfortunately, I am not in a position to initiate a change in the StORE schema. StORE is also used with other RDBMSs, and the users of those have no incentive to bless a change in the schema just to help out the PostgreSQL users. Hm, I must have misunderstood what you wanted to do, because it sure sounded like a schema change to me. But anyway --- although I do not want to offer this as a supported option, there is nothing to stop you from altering PG_PROTOCOL_EARLIEST in your build. See src/include/libpq/pqcomm.h. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] FE/BE Protocol - Specific version
On Friday 29 August 2003 15:37, Bruce Badger wrote: On Fri, 2003-08-29 at 23:35, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: So, being able to stop connections trying to use old protocol versions would be very helpful in this case. Wouldn't it be better to have StORE run a select version() after connecting? Well, his point is that old versions of his client code wouldn't know to do that. However, I don't think that what he's suggesting is a suitable answer either --- he wants to rely on a chance coincidence, namely that we're upgrading the FE/BE protocol at the same time that he wants to make an incompatible application-level change. So, if it did come to pass that rejecting connections on the basis of protocol version was possible, then I could fix the broken encoding implementation. Otherwise, I think I'll have to wait for the next chance coincidence. ... unless anyone has any better ideas? :-/ 1. Run new versions of the database on a different port - only the new client will know to look there. 2. Write a small proxy to simulate #1 (in case PG is serving other clients) - only allow access to the StORE db from localhost 3. Write a small proxy to determine which version of the protocol is in use, and allow/deny access as required. -- Richard Huxton Archonet Ltd ---(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] FE/BE Protocol - Specific version
On Fri, 2003-08-29 at 12:09, Tom Lane wrote:
Bruce Badger [EMAIL PROTECTED] writes:
Unfortunately, I am not in a position to initiate a change in the StORE
schema. StORE is also used with other RDBMSs, and the users of those
have no incentive to bless a change in the schema just to help out the
PostgreSQL users.
Hm, I must have misunderstood what you wanted to do, because it sure
sounded like a schema change to me. But anyway --- although I do not
want to offer this as a supported option, there is nothing to stop you
from altering PG_PROTOCOL_EARLIEST in your build. See
src/include/libpq/pqcomm.h.
Tom, just curious as to what your resistance is to this feature? ISTM
that making this admin modifiable doesn't hurt anyone and could be
helpful to some people.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] FE/BE Protocol - Specific version
Robert Treat [EMAIL PROTECTED] writes: Tom, just curious as to what your resistance is to this feature? ISTM that making this admin modifiable doesn't hurt anyone and could be helpful to some people. Admin modifiable at what level? I don't believe that the feature is valuable enough to warrant defining, implementing, and documenting a GUC variable, let alone adding a pg_hba.conf column which one could imagine someone wanting instead. I suggested a simple source code change, and I think that's quite sufficient when we have only one request for it with a not-very-compelling rationale. There are much more useful tweaks (eg, altering BLCKSZ) that we have equivalent levels of support for. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
