Re: [HACKERS] 8.4 release planning
On 1/26/09, Josh Berkus j...@agliodbs.com wrote: All, 1) having the last CF on Nov. 1 was a mistake. That put us square in the path of the US Christian holidays during the critical integration phase .. which means we haven't really had 3 months of integration, we've had *two*. Actually, I'm thinking about this again, and made a mistake about the mistake. The *original plan* was that we were not going to accept any new patches for Nov-CF. Just revised patches from eariler Fests. We didn't stick to that, which is mostly why we are still reviewing now. I don't recall us discussing that, but it sounds like it might help next cycle. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About postgresql8.3.3 build in MS VS2005
Hiroshi's ossp-uuid build is the latest win32 build, and what we shipped with 8.3.4. On 10/11/08, Magnus Hagander [EMAIL PROTECTED] wrote: iihero wrote: Hi, Thanks for your information. Very appreciated! When I convert the file as encoded as UTF-8, there will be no errors. For my understanding, if the file is encoded as UTF-8, the first 3 bytes will be efbbbf. No, this is not necessary. That's the BOM (Byte Order Mark), but it's not mandatory. Many editors on Windows put it there, most (I think) editors on other platforms don't. Besides this, ossp-uuid seems very hard to find a win32 build version. Is there comment int the wiki? I just find one in the mail list, which says that there is one at http://winpg.jp/~saito/pg_work/OSSP_win32/ There has been a lot of issues with that one. I don't know if there has been a release of the fixed version - I know Hiroshi Saito worked with them to get the fix into their tree, just not if it's been released yet. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: move column defaults into pg_attribute along with attacl
pgadmin has some umm, interesting queries over pg_depends. It sounds like this change could complicate those. I doubt it's an insurmountable problem of course. On 9/21/08, Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: A possible objection to this plan is that if the column-level privileges patch doesn't get in, then we're left with a useless column in pg_attribute. But an always-null column doesn't cost much of anything, and we know that sooner or later we will support per-column ACLs: they are clearly useful as well as required by spec. So any inefficiency would only be transient anyway. Right. I don't see this objection holding much water as column privs are something that many in the community would like to see. If Stephen's patch doesn't get in, it is likely it would (or a derivative there of) within the 8.5 release cycle. If anything it just provides a stepping stone. I see nothing wrong with that. Yah. However, I started to look at doing this and immediately hit a stumbling block: we need a representation in pg_depend for a column's default expression (as distinct from the column itself). Currently this consists of classid = OID of pg_attrdef, objid = OID of the default's row in pg_attrdef; both of which would disappear if we get rid of pg_attrdef as an actual catalog. I can think of a way around that: represent a default expression using classid = OID of pg_attribute, objid = OID of table, objsubid = column attnum. This is distinct from the column itself, which is represented with classid = OID of pg_class. It seems pretty ugly and potentially confusing though. Also there would be a compatibility issue for clients that examine pg_depend. Is it ugly enough to scuttle the whole concept of merging pg_attrdef into pg_attribute? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Overhauling GUCS
On 8/18/08, Magnus Hagander [EMAIL PROTECTED] wrote: Dave Page wrote: On Mon, Aug 18, 2008 at 8:51 PM, Gregory Stark [EMAIL PROTECTED] wrote: The main problem that I've seen described is what I mentioned before: allowing adjusting the postgresql.conf GUC settings by remote users who don't have shell access. Which pgAdmin has done perfectly well for years, as long as the config is all in one file. I'll argue it's not done it perfectly well (it's not particularly user-friendly), but it has certainly *done* it... I mean it's able to read write the config file correctly. I agree the ui is, umm, sub-optimal. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
