Re: [HACKERS] Time to update list of contributors
IMHO, it may not be a bad idea to list countries , it shows the diversity of the community. -Original Message- From: Gregory Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org; [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: 28/11/2007 06:30 Subject: Re: [HACKERS] Time to update list of contributors Josh Berkus [EMAIL PROTECTED] writes: All, Time for the annual update of this list: ... Greg Stark, USA I'm not sure what the countries are supposed to signify but that's neither the country I hail from nor where I'm currently living. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] String encoding during connection handshake
Martin is actually right. No assumption is made about the encoding of the password. The password is recieved as a set of bytes over the wire-level protocol and then processed accordingly as per your pg_hba settings. please refer to auth.c method recv_password_packet(Port *port). The comment on the last line of the method might be of your intrest, and i quote Return the received string, Note we do not attempt to do any character set conversion on it; since we don't know the client's encoding, there woudn't be much point / Usama From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Tue 11/27/2007 8:55 PM To: Martijn van Oosterhout Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] String encoding during connection handshake On Tuesday 27 November 2007, Martijn van Oosterhout wrote: I was under the impression that the username/password, had no encoding, they are Just a Bunch of Bits, i.e. byte[]. I cannot agree to that, simply because Postgres supports (or at least claims to) multi-byte characters. And user names, passwords and database names are character strings. Looking at it another way, the encoding is part of the password. The correctly entered password in the wrong encoding is also wrong, because the matching is done at the byte level. I'm afraid that is true to some extent, that's why I'm asking in the first place. A user should be able to authenticate as long as he/she is able to write the password, regardless of the OS's locale setting. This is all AIUI, Thanks fot the input, I'm waiting for others, too. Or point me to the relevant source files. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] pg_get_tabledef
Hi, i was following a thread some time ago where adding a function pg_get_tabledef was one of the TODOs for 8.2, but it somehow didn't make it to the release perhaps because the functionality was not clearly defined? not sure. Anyway i happen to come up with a function for pg_get_tabledef which works something like following postgres=# select pg_get_tabledef(16388) ; pg_get_tabledef CREATE TABLE public.dept ( deptno numeric(2,0) NOT NULL, dname character varying(14), loc character varying(13) ) WITHOUT OIDS; (1 row) i wanted to submit a patch for this, IFF the community wants this function. The rationale is obviously to help Application developers writing applications like pgAdmin. Currently this part of SQL needs to be constructed manually for postgres by the tools. it is arguable that a table defintion will have constraints , triggers etc as well, and they can be added without much problem, but i think if a tool needs to construct an SQL for all table related objects then functions are already available for them like pg_get_constraintdef, pg_get_ruledef, pg_get_indexdef, pg_get_triggerdef etc i understand that you guys don't like someone to develop a patch in isolation and just come up with it one day, but it really came out as a by-product of some other work , and i thought you guys might be interested in it. if it is desired, i will submit a patch for it, within a day or so. Regards, Usama Munir EnterpriseDB (www.enterprisedb.com)
Re: [HACKERS] pg_get_tabledef
I think using pg_dump in some cases is a good option , but not all the time, having a function makes it much cleaner to use Consider pgAdmin lets say (and there are many such applications out there) , you need to show object DDL on the RHP and its nicely formatted and you can copy paste it and then perhaps export it in an SQL file. Now imagine you need to spawn a new process from inside the app for pg_dump, and then make it write to a file and then read the file to display the object DDL, which is possible but very messy looking code. Then there are issues with launching external processes on certain platforms (for example in Java if you start a new process from the runtime(), you need to make sure you properly flush out its stdout and stderr streams otherwise it can go in a deadlock etc), i would use a function, if available anyday Additionally there are such functions for other objects, but for tables you needed to construct it manually, so i also thought this would just complete the set and make it easier to write an SQL / DDL exporting app. Naz Gassiep wrote: Just a question, is there any advantage to having this then building a function in applications that wrap and use pg_dump with a few options? Surely that's a more appropriate way to achieve this functionality? - Naz. Usama Munir wrote: Hi, i was following a thread some time ago where adding a function *pg_get_tabledef* was one of the TODOs for 8.2, but it somehow didn't make it to the release perhaps because the functionality was not clearly defined? not sure. Anyway i happen to come up with a function for pg_get_tabledef which works something like following /postgres=# select pg_get_tabledef(16388) ; pg_get_tabledef CREATE TABLE public.dept ( deptno numeric(2,0) NOT NULL, dname character varying(14), loccharacter varying(13) ) WITHOUT OIDS; /(1 row) i wanted to submit a patch for this, IFF the community wants this function. The rationale is obviously to help Application developers writing applications like pgAdmin. Currently this part of SQL needs to be constructed manually for postgres by the tools. it is arguable that a table defintion will have constraints , triggers etc as well, and they can be added without much problem, but i think if a tool needs to construct an SQL for all table related objects then functions are already available for them like pg_get_constraintdef, pg_get_ruledef, pg_get_indexdef, pg_get_triggerdef etc i understand that you guys don't like someone to develop a patch in isolation and just come up with it one day, but it really came out as a by-product of some other work , and i thought you guys might be interested in it. if it is desired, i will submit a patch for it, within a day or so. Regards, Usama Munir EnterpriseDB (www.enterprisedb.com) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_get_tabledef
When you say pgdump library, do you mean taking all catalog querying functionality into a contrib like module , exposed as functions and then have a simple pgdump executable which calls those functions to dump to a file, because you would still need a pgdump executable i suppose for people to be able to backup their stuff. Is my understanding somewhere near actual idea or i am way off here? Are there any discussions on this topic which could give me a little more idea? because i would definitely like to take a shot at this. Regards, Usama Munir EnterpriseDB (www.enterprisedb.com) Andrew Dunstan wrote: Usama Munir wrote: I think using pg_dump in some cases is a good option , but not all the time, having a function makes it much cleaner to use That's why having a shared pgdump library as has been previously mentioned is by far the best solution. We have discussed this before, and factoring out this functionality into a shared lib is what needs to be done. I'm not convinced it is as much work as Tom suggests, but it is certainly a non-trivial task. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_get_tabledef
Got it. Thanks for the clarification , i suppose the way you described it , it needs to go over libpq for the database interface, not the HeapTuple / Form_pg_* , way. I guess the way forward for me would be to crawl back in my corner, write up a mini - spec of how i intend to implement it and get back to you guys. Thanks for your feedback. Regards, Usama Munir. Andrew Dunstan wrote: I mean as a shared library - a .so for Unix (or whatever the flavor of unix uses instead) or a DLL on WIndows. And no, it would not be in contrib - as I mentioned in another thread yesterday I want to propose that contrib disappear. Certainly pg_dump would use the library, and retain all the file handling processing it does now. But we could also link it into psql, for example, and expose the results via \ commands. If you want to have a go at that you'll probably make lots of people very happy. cheers andrew Usama Munir wrote: When you say pgdump library, do you mean taking all catalog querying functionality into a contrib like module , exposed as functions and then have a simple pgdump executable which calls those functions to dump to a file, because you would still need a pgdump executable i suppose for people to be able to backup their stuff. Is my understanding somewhere near actual idea or i am way off here? Are there any discussions on this topic which could give me a little more idea? because i would definitely like to take a shot at this. Regards, Usama Munir EnterpriseDB (www.enterprisedb.com) Andrew Dunstan wrote: Usama Munir wrote: I think using pg_dump in some cases is a good option , but not all the time, having a function makes it much cleaner to use That's why having a shared pgdump library as has been previously mentioned is by far the best solution. We have discussed this before, and factoring out this functionality into a shared lib is what needs to be done. I'm not convinced it is as much work as Tom suggests, but it is certainly a non-trivial task. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
