Re: [HACKERS] proposal sql: labeled function params
2008/8/16 Decibel! [EMAIL PROTECTED]: On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote: value AS name, on the other hand, accomplishes the same in a more SQL-looking fashion with no new reserved word (since AS is already fully reserved). would it be more natural / SQL-like to use value AS name or name AS value ? IMHO, *natural* would be name *something* value, because that's how every other language I've seen does it. SQL-like would be value AS name, but I'm not a fan of putting the value before the name. And I think value AS name will just lead to a ton of confusion. Since I think it'd be very unusual to do a = (b = c), I'd vote that we just go with =. Anyone trying to do a = b = c should immediately question if that would work. I'll look on this syntax - what is really means for implementation. I thing, mostly of us prefer this or similar syntax. Regards Pavel Stehule -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 -- 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] Replay attack of query cancel
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Andrew Gierth wrote: 2. The server accepts either the old-style or the secure cancel request from the client, but doesn't allow old-style requests once a valid secure request has been seen. Hmm, I think there should be a way to turn off acceptance of old-style without necessarily requiring a new-style request. Otherwise, how are you protected from DoS if you have never sent a cancel request at all? Assuming you were using SSL, it's hard to see how an attacker is going to get your cancel key without having seen a cancel request. Not only that, but he'll have to see an *old-style* cancel request, since the new style doesn't contain the key. And if you're *not* using SSL, the attacker can just sniff they key off the initial packet instead. However, I dislike Andrew's proposal above even without that issue, because it means *still more* changeable state that has to be magically shared between postmaster and backends. If we want to have a way for people to disable insecure cancels, we should just have a postmaster configuration parameter that does it. Agreed. Your security policy also should not depend on what your client happens to do, it should be enforceable. //Magnus -- 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 sql: labeled function params
On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote: 2008/8/16 Decibel! [EMAIL PROTECTED]: On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote: value AS name, on the other hand, accomplishes the same in a more SQL-looking fashion with no new reserved word (since AS is already fully reserved). would it be more natural / SQL-like to use value AS name or name AS value ? IMHO, *natural* would be name *something* value, because that's how every other language I've seen does it. SQL-like would be value AS name, but I'm not a fan of putting the value before the name. And I think value AS name will just lead to a ton of confusion. Since I think it'd be very unusual to do a = (b = c), I'd vote that we just go with =. Anyone trying to do a = b = c should immediately question if that would work. I'll look on this syntax - what is really means for implementation. I thing, mostly of us prefer this or similar syntax. Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) And I still don't think we need two kinds of names (argument name and label). I'd rather see us have the syntax for this be similar to python's keyword arguments, even though I'm not entirely opposed to automatically generating the name= part if it comes from existing name (variable, function argument or column name). --- Hannu -- 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 sql: labeled function params
Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? 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
Re: [HACKERS] Mini improvement: statement_cost_limit
this entire thing is not about cartesian products at all. it is about kicking out expensive queries before they even start to eat up tons of CPU. imagine a user asking for give me all phone call in the US within the past 10 years. you could kill the guy instantly because you know that this would take ages. in addition to that you know that in an OLTP context everything which is expected to take longer than X cannot be useful anyway. this has nothing to do with cartesian products or other bad things you can do in SQL. it is just a simple and heuristic check. many thanks, hans My point is that people should _know_ they are using a cartesian product, and a warning would do that for users who have no need for a cartesian product and want to be warned about a possible error. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- 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 sql: labeled function params
2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote: 2008/8/16 Decibel! [EMAIL PROTECTED]: On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote: value AS name, on the other hand, accomplishes the same in a more SQL-looking fashion with no new reserved word (since AS is already fully reserved). would it be more natural / SQL-like to use value AS name or name AS value ? IMHO, *natural* would be name *something* value, because that's how every other language I've seen does it. SQL-like would be value AS name, but I'm not a fan of putting the value before the name. And I think value AS name will just lead to a ton of confusion. Since I think it'd be very unusual to do a = (b = c), I'd vote that we just go with =. Anyone trying to do a = b = c should immediately question if that would work. I'll look on this syntax - what is really means for implementation. I thing, mostly of us prefer this or similar syntax. Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) And I still don't think we need two kinds of names (argument name and label). I'd rather see us have the syntax for this be similar to python's keyword arguments, even though I'm not entirely opposed to automatically generating the name= part if it comes from existing name (variable, function argument or column name). I wouldn't mix together two features - argument name (keyword argument) and labels. Its two different features. Regards Pavel Stehule --- Hannu -- 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 sql: labeled function params
On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? I think that we could achieve what Pavel was after by allowing one to define something similar to keyword arguments in python. maybe allow input RECORD type, which is instantiated at call time by giving extra arguments to function call: CREATE FUNCTION f_kw(r record) and then if you call it like this: SELECT ... f_kw(name='bob', age=7::int) then function gets as its input a record which can be accessed in pl/pgsql like r.name r.age and if terseness is really appreciated then the it could also be called like this SELECT ... f_kw(name, age) from people where name='bob'; which is rewritten to SELECT ... f_kw(name=name, age=age) from people where name='bob'; not sure if we should allow defining SETOF RECORD and then enable calling it with SELECT * FROM f_kw( VALUES(name='bob', age=7::int), VALUES(name='bill', age=42::int ); or somesuch -- Hannu -- 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 sql: labeled function params
Hannu it's not possible in plpgsql, because we are not able iterate via record. Pavel 2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? I think that we could achieve what Pavel was after by allowing one to define something similar to keyword arguments in python. maybe allow input RECORD type, which is instantiated at call time by giving extra arguments to function call: CREATE FUNCTION f_kw(r record) and then if you call it like this: SELECT ... f_kw(name='bob', age=7::int) then function gets as its input a record which can be accessed in pl/pgsql like r.name r.age and if terseness is really appreciated then the it could also be called like this SELECT ... f_kw(name, age) from people where name='bob'; which is rewritten to SELECT ... f_kw(name=name, age=age) from people where name='bob'; not sure if we should allow defining SETOF RECORD and then enable calling it with SELECT * FROM f_kw( VALUES(name='bob', age=7::int), VALUES(name='bill', age=42::int ); or somesuch -- Hannu -- 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] [PgFoundry] Unsigned Data Types
On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote: On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. The pg_catalog made since to me at first (especially for my application), but on reflection I believe you are right. I will remove the references to the pg_catalog schema and allow the user to add the unsigned data type to any schema. Good catch on the uninstall script. I should have written this as well. I will post an update to the wiki later tonight. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! I am glad it is useful. I needed it for my current project, and I was hoping others could use it as well. Thanks, - Ryan
Re: [HACKERS] proposal sql: labeled function params
Not able to means not implementable o not implemented ? On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule [EMAIL PROTECTED]wrote: Hannu it's not possible inNot able to plpgsql, because we are not able iterate via record. Pavel 2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? I think that we could achieve what Pavel was after by allowing one to define something similar to keyword arguments in python. maybe allow input RECORD type, which is instantiated at call time by giving extra arguments to function call: CREATE FUNCTION f_kw(r record) and then if you call it like this: SELECT ... f_kw(name='bob', age=7::int) then function gets as its input a record which can be accessed in pl/pgsql like r.name r.age and if terseness is really appreciated then the it could also be called like this SELECT ... f_kw(name, age) from people where name='bob'; which is rewritten to SELECT ... f_kw(name=name, age=age) from people where name='bob'; not sure if we should allow defining SETOF RECORD and then enable calling it with SELECT * FROM f_kw( VALUES(name='bob', age=7::int), VALUES(name='bill', age=42::int ); or somesuch -- Hannu -- 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 sql: labeled function params
Pavel Stehule [EMAIL PROTECTED] writes: 2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 08:06 +0200, Pavel Stehule wrote: 2008/8/16 Decibel! [EMAIL PROTECTED]: SQL-like would be value AS name, but I'm not a fan of putting the value before the name. And I think value AS name will just lead to a ton of confusion. Since I think it'd be very unusual to do a = (b = c), I'd vote that we just go with =. Anyone trying to do a = b = c should immediately question if that would work. I'll look on this syntax - what is really means for implementation. I thing, mostly of us prefer this or similar syntax. Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) This whole thing seems like a ridiculous idea. It's a fancy way of passing an extra parameter to the function intended to be used for a particular label purpose. Your xml function could just as easily take two functions f(name,value) instead of using a special spelling for ,. That it is easily confused with named parameters means there are huge downsides and no significant up-sides to having this trivial little bit of syntactic sugar. To say nothing that using = or anything like that would be just completely un-SQLish. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- 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] [PgFoundry] Unsigned Data Types
I can say that we have had several times to use bigint instead because of the lack of uint type in postgres. On Sun, Aug 17, 2008 at 9:03 PM, Ryan Bradetich [EMAIL PROTECTED]wrote: On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote: On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. The pg_catalog made since to me at first (especially for my application), but on reflection I believe you are right. I will remove the references to the pg_catalog schema and allow the user to add the unsigned data type to any schema. Good catch on the uninstall script. I should have written this as well. I will post an update to the wiki later tonight. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! I am glad it is useful. I needed it for my current project, and I was hoping others could use it as well. Thanks, - Ryan
[HACKERS] any psql static binary for iphone ?
Hi there, is there psql static binary, which I can use on my iphone (version 1) ? I have no mac available, so I can't compile it myself. I heard about gui tool for iphone, but it's not free and is only available from apple store, which I have no access. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 -- 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 sql: labeled function params
2008/8/17 Asko Oja [EMAIL PROTECTED]: Not able to means not implementable o not implemented ? Almost not implementable - plpgsql is too static language. On Sun, Aug 17, 2008 at 6:59 PM, Pavel Stehule [EMAIL PROTECTED] wrote: Hannu it's not possible inNot able to plpgsql, because we are not able iterate via record. Pavel 2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? I think that we could achieve what Pavel was after by allowing one to define something similar to keyword arguments in python. maybe allow input RECORD type, which is instantiated at call time by giving extra arguments to function call: CREATE FUNCTION f_kw(r record) and then if you call it like this: SELECT ... f_kw(name='bob', age=7::int) then function gets as its input a record which can be accessed in pl/pgsql like r.name r.age and if terseness is really appreciated then the it could also be called like this SELECT ... f_kw(name, age) from people where name='bob'; which is rewritten to SELECT ... f_kw(name=name, age=age) from people where name='bob'; not sure if we should allow defining SETOF RECORD and then enable calling it with SELECT * FROM f_kw( VALUES(name='bob', age=7::int), VALUES(name='bill', age=42::int ); or somesuch -- Hannu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] pgbench duration option
On Tue, 12 Aug 2008, Tom Lane wrote: This seems like a fairly bad idea, because it introduces a gettimeofday() call per transaction. There's already lots of paths through pgbench that introduce gettimeofday calls all over the place. I fail to see how this is any different. If this were worth doing (which IMHO it isn't) I think that switching the recommended practice for running pgbench to something time-based rather than transactions-based would increase the average quality of results people got considerably. How many times do you see people posting numbers that worthless because the test ran for a trivial amount of time? Seems like it happens a lot to me. This patch was already on my todo list for 8.4 and I'm glad I don't have to write it myself now. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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 Wed, 13 Aug 2008, Michael Nacos wrote: Hi there... Configuration autotuning is something I am really interested in. I have seen this page: http://wiki.postgresql.org/wiki/GUCS_Overhaul and a couple of emails mentioning this, so I wanted to ask is someone already on it? If yes, I'd like to contribute. Good time to give a status report on what's been going on with all this. With some help I just finished off an answer to problem #1 there recently, Most people have no idea how to set these. There was some concern here that work was being done on config tools without a clear vision of what was going to be tuned. See http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server for an intro on how to set the 18 most important parameters (+7 logging parameters) based on the best information I'm aware of. Circa June, Steve Atkins was looking into writing a C++/Qt GUI tuning interface application, with the idea that somebody else would figure out the actual smarts to the tuning effort. Don't know where that's at. Josh Berkus and I have been exchanging some ideas for the GUC internals overhaul and had a quick discussion about that in person last month. We've been gravitating toward putting all the extra information we'd like to push into there in an extra catalog table (pg_settings_info or something). The stuff the server needs to start can stay right where it is right now, all the other decoration can move to the table. Ideally, an external little app should also provide recommendations based on current database usage statistics -- wouldn't this constitute something akin to application-specific advice? Yes, there's a grand plan for a super-wizard that queries the database for size, index, and statistics information for figure out what to do; I've been beating that drum for a while now. Unfortunately, the actual implementation is blocked behind the dreadfully boring work of sorting out how to organize and manage the GUC information a bit better, and the moderately boring work of building a UI for modifying things. If you were hoping to work on the sexy autotuning parts without doing some of the grunt work, let me know if you can figure out how so I can follow you. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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] API for Managing pg_hba and postgresql.conf
On Thu, 14 Aug 2008, Andrew Satori wrote: What I'm seeing is a default installation protects the Data directory properly, but in so doing means that altering the configuration files, pg_hba.conf and postgresql.conf require database administrators, who should not necessarily have a level of rights to become superuser at the file system level to alter the mentioned files. This suggests you're doing something wrong, and it's no wonder you think this is a serious management problem (I consider it a minor one). In a typical installation, the data directory that contains the database and configuring files will be owned by a database user, typically postgres. DBAs should be able to get to all of those by switching to that user, without need any true superuser rights. If that isn't the case in your environment, I'm curious how you ended up there, and it's no wonder that's a serious management problem for you. I consider this area only a minor annoyance. Normally the only thing I see that you can't do as the postgres user is directly execute the database start/stop scripts that root runs (service postgresql start on RedHat for example), but since all that can be done via pg_ctl instead this is an easily scriptable issue to work around. A huge portion of the motivation here is to allow for easy to graphical administration interfaces, making the system more approachable, and to make remote administration of these files less cumbersome. There's already a bunch of work in that area going on already. Check the archives for the GUCS Overhaul and Parsing of pg_hba.conf and authentication inconsistencies threads for two long-running discussions of the fundamental server-side issues needed to pull that off. You touched on the main one here: Since most changes would require a SIGHUP, should the server process itself be alter to allow for a dynamic restart from within the environment? Many of the problems with what you're thinking of revolve around the unfortunate answers that pop up when you ask what if I try and put bad information in postgresql.conf/pg_hba.conf?; see those threads I mentioned for some context on that. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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
Greg Smith [EMAIL PROTECTED] writes: Josh Berkus and I have been exchanging some ideas for the GUC internals overhaul and had a quick discussion about that in person last month. We've been gravitating toward putting all the extra information we'd like to push into there in an extra catalog table (pg_settings_info or something). The stuff the server needs to start can stay right where it is right now, all the other decoration can move to the table. Somehow, the attraction of that idea escapes me. What we have now was named Grand Unified Configuration for a reason: it centralized the handling of what had been a mess of different things configured in different ways. I'm not eager to go backwards on that. I'm also interested to know exactly what such a table would provide that isn't already available in the form of the pg_settings view. 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
Re: [HACKERS] IN vs EXISTS equivalence
If you're still interested in testing CVS HEAD's handling of EXISTS, I've about finished what I wanted to do with it. 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
Re: [HACKERS] proposal sql: labeled function params
On Sun, 2008-08-17 at 17:59 +0200, Pavel Stehule wrote: Hannu it's not possible in plpgsql, because we are not able iterate via record. just add function for iterating over record :) create or replace function json(r record) returns varchar as $$ select '[' || array_to_string( array( select (getfieldnames(r))[i]|| ':' || getfieldvalue(r,i) from generate_subscripts(r,1) g(i)) ,',') || ']' $$ language sql immutable strict; (this is a straight rewrite of your original sample, one can also do it in a simpler way, with a function returning SETOF (name, value) pairs) postgres=# select json(name='Zdenek',age=30); json -- [name:Zdenek,age:30] (1 row) postgres=# select json(name, age) from person; json -- [name:Zdenek,age:30] (1 row) BTW, json actually requires quoting names/labels, so the answer should be [name:Zdenek,age:30] 2008/8/17 Hannu Krosing [EMAIL PROTECTED]: On Sun, 2008-08-17 at 11:08 -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) *What* are you thinking? I think that we could achieve what Pavel was after by allowing one to define something similar to keyword arguments in python. maybe allow input RECORD type, which is instantiated at call time by giving extra arguments to function call: CREATE FUNCTION f_kw(r record) and then if you call it like this: SELECT ... f_kw(name='bob', age=7::int) then function gets as its input a record which can be accessed in pl/pgsql like r.name r.age and if terseness is really appreciated then the it could also be called like this SELECT ... f_kw(name, age) from people where name='bob'; which is rewritten to SELECT ... f_kw(name=name, age=age) from people where name='bob'; not sure if we should allow defining SETOF RECORD and then enable calling it with SELECT * FROM f_kw( VALUES(name='bob', age=7::int), VALUES(name='bill', age=42::int ); or somesuch -- Hannu -- 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 Sun, 17 Aug 2008, Tom Lane wrote: What we have now was named Grand Unified Configuration for a reason: it centralized the handling of what had been a mess of different things configured in different ways. I'm not eager to go backwards on that. No need to change anything related to how the configuration is done. There's really only two things wrong with what's there right now IMHO and they don't require any changes to the internals, just what's shown: 1) The view should show both how the user defined the setting and how it's represented internally. Basically something that looks like this: select name,current_setting(name) as input_setting,setting from pg_settings; 2) Expose the default value. I'm also interested to know exactly what such a table would provide that isn't already available in the form of the pg_settings view. Links to the relevant documentation and a place to save both default and user comments about the setting were two things being considered that seemed a really bad fit to tack onto the GUC structure. There's some others. The main point is that that nobody wants to have to tinker with the core GUC itself just to decorate it with more information, that is complicated enough as it is. One might make a case that the stuff the GUC must handle (settings, units, type, defaults, etc.) could be usefully separated from all the more documentation-oriented bits stored there right now (category, descriptions), and that the existing documentation bits could move over to the table along with the hyperlinks and such. Doing that adds another place to have to edit, but I think there's an even exchange available there because it enables easy auto-generation of the postgresql.conf file at initdb time from that table + pg_settings. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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 sql: labeled function params
Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) The problem with this is that SELECT foo(a = b) ...is already valid syntax. It means compare a with b and pass the resulting boolean to foo. I'm almost positive that changing this would break all kinds of existing code (and probably create a lot of grammar problems too). It's not an issue with SET because in that case the name= part of the syntax is required rather than optional. Any other operator you pick is going to have this same problem unless it's already impossible to use that operator as part of an expression. For that reason, while I'm not convinced of the value of the feature, if we're going to support it then ISTM that expr AS label is the way to go. That also has the advantage of being consistent with the syntax for table and column aliasing. ...Robert -- 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 Aug 17, 2008, at 1:48 PM, Greg Smith wrote: On Wed, 13 Aug 2008, Michael Nacos wrote: Hi there... Configuration autotuning is something I am really interested in. I have seen this page: http://wiki.postgresql.org/wiki/ GUCS_Overhaul and a couple of emails mentioning this, so I wanted to ask is someone already on it? If yes, I'd like to contribute. Good time to give a status report on what's been going on with all this. With some help I just finished off an answer to problem #1 there recently, Most people have no idea how to set these. There was some concern here that work was being done on config tools without a clear vision of what was going to be tuned. See http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server for an intro on how to set the 18 most important parameters (+7 logging parameters) based on the best information I'm aware of. Circa June, Steve Atkins was looking into writing a C++/Qt GUI tuning interface application, with the idea that somebody else would figure out the actual smarts to the tuning effort. Don't know where that's at. First pass is done. Needs a little cleanup before sharing. I spent a fair while down OS-specific-hardware-queries rathole, but I'm better now. Cheers, Steve -- 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 sql: labeled function params
On Sun, 2008-08-17 at 18:24 -0400, Robert Haas wrote: Actually the most natural syntax to me is just f(name=value) similar to how UPDATE does it. It has the added benefit of _not_ forcing us to make a operator reserved (AFAIK = can't be used to define new ops) The problem with this is that SELECT foo(a = b) ...is already valid syntax. uups, completely forgot dual use of = for both assignment and comparison. It means compare a with b and pass the resulting boolean to foo. I'm almost positive that changing this would break all kinds of existing code (and probably create a lot of grammar problems too). It's not an issue with SET because in that case the name= part of the syntax is required rather than optional. Maybe we can do without any keyword arguments or labeled function params if we define a way to construct records in-place. something like RECORD( 'Zdanek'::text AS name, 22::int AS age); -- like SELECT or RECORD( name 'Zdanek'::text, age 22::int); -- like CREATE TABLE/TYPE or RECORD(name, age) from sometable; -- get values types from table ? Then we could pass these records to any PL for processing with minimal confusion to programmer, and without introducing new concepts like variadic argument position labels - Hannu -- 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] Patch: plan invalidation vs stored procedures
On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote: Asko Oja [EMAIL PROTECTED] writes: Is it possible to get it into some official 8.3.x release This is not the kind of patch we put into stable branches. Does this really count as a user-visible change, except in the sense that they won't see things erroring out? It doesn't add new syntax, as far as I can tell. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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 sql: labeled function params
uups, completely forgot dual use of = for both assignment and comparison. Maybe we can do without any keyword arguments or labeled function params if we define a way to construct records in-place. That sounds a lot cleaner to me. something like RECORD( 'Zdanek'::text AS name, 22::int AS age); -- like SELECT or RECORD( name 'Zdanek'::text, age 22::int); -- like CREATE TABLE/TYPE or RECORD(name, age) from sometable; -- get values types from table In most cases, you can just do this using SELECT without the need for any special syntax. For example: SELECT json(p) FROM person p; SELECT json(p) FROM (SELECT first_name, last_name FROM person) p; The only problem is that this doesn't work if you try to put the select into the attribute list: SELECT json(select first_name, last_name) FROM person p; ERROR: syntax error at or near select SELECT json((select first_name, last_name)) FROM person p; ERROR: subquery must return only one column Unfortunately this is a pretty common situation, because you might easily want to do: SELECT json((select first_name, last_name)), age FROM person p; ...and you are out of luck. I'm not sure whether the ROW() syntax could possibly be extended to address this problem. It doesn't seem to help in its present form. Then we could pass these records to any PL for processing with minimal confusion to programmer, and without introducing new concepts like variadic argument position labels Amen. ...Robert -- 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
Steve, First pass is done. Needs a little cleanup before sharing. I spent a fair while down OS-specific-hardware-queries rathole, but I'm better now. Gods, I hope you gave up on that. You want to use SIGAR or something. --Josh -- 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] Patch: plan invalidation vs stored procedures
David Fetter wrote: On Sat, Aug 16, 2008 at 09:40:19PM -0400, Tom Lane wrote: Asko Oja [EMAIL PROTECTED] writes: Is it possible to get it into some official 8.3.x release This is not the kind of patch we put into stable branches. Does this really count as a user-visible change, except in the sense that they won't see things erroring out? It doesn't add new syntax, as far as I can tell. So what? That is not the only criterion for backpatching. The bigger the change the more resistance there will be to backpatching it. Code stability is a major concern. cheers andrew -- 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 postgres-r setup.
leiyonghua 写道: Markus Wanner 写道: Hello Leiyonghua, leiyonghua wrote: at node2, and the psql command is hung up, NOTICE: Applying for membership in the communication group... NOTICE: Successfully joined the replication group. Now recovering schema... I've just tested the very same here with ensemble, and could reproduce the situation. It had to do with the ensemble receive buffer being too small to hold the recovery data. That's fixed in today's snapshot. With that I've been able to replicate simple tuples again. that's cool ! i will try later. Regards Markus Wanner leiyonghua today, i try the snap-shot postgres-r-20080813.diff and still same status. leiyonghua -- 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] migrate data 6.5.3 - 8.3.1
Tom Lane wrote: I wonder if you need these self defined aggregates at all, most or all of them are in 8.3 already. They aren't self defined in 6.5 either. So i can't just delete those AGGREGATEs? I think what is happening is that he's trying to force a 7.x pg_dump to dump from the 6.5 server (with -i no doubt), and it's just tremendously confused about what's what and what it should dump. These errors occurs when i'm trying to restore dump from 6.5 on 8.3. -- alexander lunyov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
