Re: [HACKERS] [PATCHES] Enums patch v2
On Wed, Dec 20, 2006 at 01:39:58AM +, Tom Dunstan wrote: Not with this patch, and AFAIK not possible generally, without writing separate I/O functions for each type. I'd love to be able to do that, but I don't think it's possible currently. The main stumbling block is the output function (and cast-to-text function), because output functions do not get provided the oid of the type that they're dealing with, for security reasons IIRC. It was never clear to me why I/O functions should ever be directly callable by a user (and hence open to security issues), but apparently it was enough to purge any that were designed like that from the system, so I wasn't going to go down that road with the patch. I worked around this in taggedtypes by indeed creating seperate copies of the i/o functions on demand and at execution time looking up the required type from the function signiture. The only solution indeed is to change the calling convention if the I/O functions so that the relevent datatype oid stored in a safe place, that isn't set for normal function calls. BTW, being able to call type i/o functions directly is very useful. For example date_in(text_out(blah)) is a form of cast between types that don't usually have a cast. If you change the calling convention as indicated, that trick will still work, just not for types with the restricted i/o functions. Also, it's not just I/O functions that are the issue, consider the enum-to-integer cast. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Enums patch v2
Martijn van Oosterhout wrote: Also, it's not just I/O functions that are the issue, consider the enum-to-integer cast. er, what cast? :-) IIRC Tom hasn't provided one. If you don't break the enum abstraction there should be no need for one, and given the implementation it's not quite trivial - probably the best way if this is needed would be to precalculate it at type creation time and store the value in an extra column in pg_enum. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Enums patch v2
Andrew Dunstan wrote: As for efficiency, I agree with what Tom says about alignment and padding dissolving away any perceived advantage in most cases. If we ever get around to optimising record layout we could revisit it. I don't, because there are always those that are knowledgeable enough to know how to reduce space lost to padding. So it would be nice to have 2-byte enums on-disk, and resolve them based on the column's typid. But then, I'm not familiar with the patch at all so I'm not sure if it's possible. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: 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] [PATCHES] Enums patch v2
Alvaro Herrera wrote: Andrew Dunstan wrote: As for efficiency, I agree with what Tom says about alignment and padding dissolving away any perceived advantage in most cases. If we ever get around to optimising record layout we could revisit it. I don't, because there are always those that are knowledgeable enough to know how to reduce space lost to padding. So it would be nice to have 2-byte enums on-disk, and resolve them based on the column's typid. But then, I'm not familiar with the patch at all so I'm not sure if it's possible. The trouble is that we have one output routine for all enum types. See previous discussions about disallowing extra params to output routines. So if all we have is a 2 byte offset into the list of values for the given type, we do not have enough info to allow the output routine to deduce which particular enum type it is dealing with. With the globally unique oid approach it doesn't even need to care - it just looks up the corresponding value. Note that this was a reduction from the previously suggested (by TGL) 8 bytes. I'm not a big fan of ordering columns to optimise record layout, except in the most extreme cases (massive DW type apps). I think visible column order should be logical, not governed by physical considerations. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Enums patch v2
Alvaro Herrera [EMAIL PROTECTED] writes: I don't, because there are always those that are knowledgeable enough to know how to reduce space lost to padding. So it would be nice to have 2-byte enums on-disk, and resolve them based on the column's typid. But then, I'm not familiar with the patch at all so I'm not sure if it's possible. Remember that the value has to be decodable by the output routine. So the only way we could do that would be by creating a separate output function for each enum type. (That is, a separate pg_proc entry ... they could all point at the same C function, which would have to check which OID it was called as and work backward to determine the enum type.) While this is doubtless doable, it's slow, it bloats pg_proc, and frankly no argument has been offered that's compelling enough to require it. The alignment issue takes enough air out of the space-saving argument that it doesn't seem sufficient to me. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Enums patch v2
Andrew Dunstan [EMAIL PROTECTED] writes: I'm not a big fan of ordering columns to optimise record layout, except in the most extreme cases (massive DW type apps). I think visible column order should be logical, not governed by physical considerations. Well as long as we're talking shoulds the database should take care of this for you anyways. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] Enums patch v2
Alvaro Herrera wrote: I don't, because there are always those that are knowledgeable enough to know how to reduce space lost to padding. So it would be nice to have 2-byte enums on-disk, and resolve them based on the column's typid. But then, I'm not familiar with the patch at all so I'm not sure if it's possible. Not with this patch, and AFAIK not possible generally, without writing separate I/O functions for each type. I'd love to be able to do that, but I don't think it's possible currently. The main stumbling block is the output function (and cast-to-text function), because output functions do not get provided the oid of the type that they're dealing with, for security reasons IIRC. It was never clear to me why I/O functions should ever be directly callable by a user (and hence open to security issues), but apparently it was enough to purge any that were designed like that from the system, so I wasn't going to go down that road with the patch. Cheers Tom ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
