Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

On Mon, Nov 16, 2009 at 08:29, David Fetter wrote: > On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >> On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: >> > David Fetter writes: >> > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: >> > >> Peter Eisentraut wr

Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: > On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: > > David Fetter writes: > > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: > > >> Peter Eisentraut wrote: > > >>> /home/peter/commit-msg > > >> er, what? > > >

Re: [HACKERS] Summary and Plan for Hot Standby

Tatsuo Ishii wrote: > In my understanding, Parse will aquire locks on the target table. Is > this harmless? That's ok, you can take AccessShareLocks in a standby. All queries lock the target table (in AccessShare mode). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Se

Re: [HACKERS] Summary and Plan for Hot Standby

> Tatsuo Ishii wrote: > > Just a question: > > > > - Does Hot Standby allow to use prepared query (not prepared > > transaction) in standby? I mean: Parse message from frontend can be > > accepted by standby? > > Yes. In my understanding, Parse will aquire locks on the target table. Is this

Re: [HACKERS] Summary and Plan for Hot Standby

Tatsuo Ishii wrote: > Just a question: > > - Does Hot Standby allow to use prepared query (not prepared > transaction) in standby? I mean: Parse message from frontend can be > accepted by standby? Yes. > - Can we create tempory tables in standby? No, because creating a temporary table needs

Re: [HACKERS] ORDER BY vs. volatile functions

> "Tom" == Tom Lane writes: >> This query: >> select random() from generate_series(1,10) order by random(); >> produces sorted output. >> Should it? Tom> It always has; we'd doubtless break some apps if we changed that. For bonus weirdness: select distinct random(),random() from gener

Re: [HACKERS] New VACUUM FULL

On Mon, 2009-11-16 at 13:37 +0900, Itagaki Takahiro wrote: > Jeff Davis wrote: > > > You left INPLACE in the patch > > Oops, removed. > > > Sounds fine, but worth a mention in the documentation. Just add to the > > "columns" part of the VACUUM page something like: "If specified, implies > > ANA

Re: [HACKERS] limit to default display in psql

Robert Treat writes: > Is there some significance to the 128 other than simple formatting? I think it's just an arbitrary restriction :-( > Also, if anyone knows when pg_attrdef.adsrc became unreliable, that would > save > me some trouble. Thanks in advance. It has never been reliable.

Re: [HACKERS] proposal: using PQexecParams in psql (using variables as real params)

Pavel Stehule wrote: > I propose to add possibility to use psql variables as real query > parameters. The goal of this proposal is simplification of creating > psql based commands. > postgres=# \pexec > Separately passing parameters is on. > postgres=# select upper(:message); There might be go

Re: [HACKERS] ORDER BY vs. volatile functions

Andrew Gierth writes: > This query: > select random() from generate_series(1,10) order by random(); > produces sorted output. > Should it? It always has; we'd doubtless break some apps if we changed that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-h

[HACKERS] limit to default display in psql

In the following query (used by psql to show attribute defaults) SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod), (SELECT substring(pg_catalog.pg_get_expr(d.adbin, d.adrelid) for 128) FROM pg_catalog.pg_attrdef d WHERE d.adrelid = a.attrelid AND d.adnum = a.attnum AND a

[HACKERS] ORDER BY vs. volatile functions

This query: select random() from generate_series(1,10) order by random(); produces sorted output. Should it? -- Andrew (irc:RhodiumToad) -- 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] Aggregate ORDER BY patch

> "Tom" == Tom Lane writes: >> What about error handling? If the user specifies agg(distinct x) >> where x is not sortable, do we leave it to the planner to detect >> that (which means not reporting the error position?) Tom> Well, at the moment there's only going to be a sort-based Tom>

Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

On sön, 2009-11-15 at 17:09 -0500, Tom Lane wrote: > David Fetter writes: > > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: > >> Peter Eisentraut wrote: > >>> /home/peter/commit-msg > >> er, what? > > I'm suspecting a misfired script somewhere. > > No doubt "cvs commit -m ~/comm

Re: [HACKERS] named parameters in SQL functions

2009/11/16 Robert Haas : > On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan wrote: >> Robert Haas wrote: >>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan >>> wrote: Robert Haas wrote: >> (But having said that, an alternate qualification name is something >> that could be implement

Re: [HACKERS] Aggregate ORDER BY patch

2009/11/16 Andrew Gierth : >> "Hitoshi" == Hitoshi Harada writes: > >  >> What case exactly would you consider an error? When an order by >  >> expression references a lower (more deeply nested) query level >  >> than any of the actual arguments? > >  Hitoshi> It's only that I felt not intuiti

Re: [HACKERS] named parameters in SQL functions

2009/11/16 Andrew Dunstan : > > > Robert Haas wrote: >> >> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan >> wrote: >> >>> >>> Robert Haas wrote: >>> > > (But having said that, an alternate qualification name is something > that could be implemented if there were any agreement on what

Re: [HACKERS] New VACUUM FULL

Jeff Davis wrote: > You left INPLACE in the patch Oops, removed. > Sounds fine, but worth a mention in the documentation. Just add to the > "columns" part of the VACUUM page something like: "If specified, implies > ANALYZE". Added. > Other than these two minor issues, I don't see any problem

Re: [HACKERS] Rejecting weak passwords

"Albe Laurenz" wrote: > I wrote: > > Following the discussions in > > http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php > > and > > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php , > > here are patches for > > > > a) a hook in backend/commands/user.c that allo

Re: [HACKERS] Summary and Plan for Hot Standby

Just a question: - Does Hot Standby allow to use prepared query (not prepared transaction) in standby? I mean: Parse message from frontend can be accepted by standby? - Can we create tempory tables in standby? -- Tatsuo Ishii SRA OSS, Inc. Japan > After some time thinking about the best way

[HACKERS] Apprentices? (was =patch - Report the schema...)

On Nov 15, 2009, at 5:14 PM, Andrew Dunstan wrote: Then I think we need to start being more creative about ways to ease the path for people who want to get people involved. With that as an inspiration, I'd like to offer a modest proposal: Apprentices. In my case, I would be very exciting

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan wrote: > Robert Haas wrote: >> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan >> wrote: >>> Robert Haas wrote: > (But having said that, an alternate qualification name is something > that could be implemented if there were any agreement on

Re: [HACKERS] Aggregate ORDER BY patch

Andrew Gierth writes: > What about error handling? If the user specifies agg(distinct x) where > x is not sortable, do we leave it to the planner to detect that (which > means not reporting the error position?) Well, at the moment there's only going to be a sort-based implementation, so I don't o

Re: [HACKERS] Aggregate ORDER BY patch

> "Tom" == Tom Lane writes: Tom> I agree with Hitoshi that this seems to be a hack to deal with the [snip] So copying the way that SELECT DISTINCT works would be the way to go? i.e. keeping separate lists in the parse node for sorting and distinct? What about error handling? If the user s

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 10:05 PM, Tom Lane wrote: > Robert Haas writes: >> I don't see why it would need to be a reserved word.  We're not >> changing how it gets parsed, just what it means.  At any rate >> "FUNCTION." is a 9-character prefix, which is rather longer than I >> would prefer. > > Th

Re: [HACKERS] Add YAML option to explain

Greg Sabino Mullane wrote: > On 08/28/2009 02:16 PM, Greg Sabino Mullane wrote: > > Attached patch adds YAML output option to explain: > > explain (format YAML) select * from information_schema.columns; > > Updated version of the patch attached, fixes two small errors. I've reviewed your patch

Re: [HACKERS] named parameters in SQL functions

Robert Haas wrote: On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan wrote: Robert Haas wrote: (But having said that, an alternate qualification name is something that could be implemented if there were any agreement on what to use.) Well that is the tricky part, for sure.

Re: [HACKERS] named parameters in SQL functions

Robert Haas writes: > I don't see why it would need to be a reserved word. We're not > changing how it gets parsed, just what it means. At any rate > "FUNCTION." is a 9-character prefix, which is rather longer than I > would prefer. This from the guy who likes 40-character function names?

Re: [HACKERS] named parameters in SQL functions

Andrew Dunstan writes: > Robert Haas wrote: >> Well that is the tricky part, for sure. I would personally prefer >> something like ${name} rather than a prefix, but I think you're likely >> to veto that outright. So, anything reasonably short would be an >> improvement over the status quo. self

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan wrote: > Robert Haas wrote: >>> >>> (But having said that, an alternate qualification name is something >>> that could be implemented if there were any agreement on what to use.) >>> >> >> Well that is the tricky part, for sure.  I would personally p

Re: [HACKERS] named parameters in SQL functions

Robert Haas wrote: (But having said that, an alternate qualification name is something that could be implemented if there were any agreement on what to use.) Well that is the tricky part, for sure. I would personally prefer something like ${name} rather than a prefix, but I think you're

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 8:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote: >>> Well, if the funcname.varname gadget will work, as you suggest elsewhere it >>> could, I think that would suffice. I had assumed that was just something in >>> the

Re: [HACKERS] named parameters in SQL functions

Andrew Chernow writes: > Tom Lane wrote: >> It's certainly true that the function name itself is not immune from >> conflicts of that sort ... in fact I think we saw a bug report recently >> from someone who had intentionally chosen a plpgsql function name equal >> to a table name used in the func

Re: [HACKERS] Aggregate ORDER BY patch

> "Hitoshi" == Hitoshi Harada writes: >> What case exactly would you consider an error? When an order by >> expression references a lower (more deeply nested) query level >> than any of the actual arguments? Hitoshi> It's only that I felt not intuitive. To me, arguments are Hitoshi> reg

Re: [HACKERS] named parameters in SQL functions

Tom Lane wrote: Andrew Chernow writes: Tom Lane wrote: (But having said that, an alternate qualification name is something that could be implemented if there were any agreement on what to use.) Would something like ARG.name be acceptable? It all depends on how likely you think it is that

Re: [HACKERS] named parameters in SQL functions

Andrew Chernow writes: > Tom Lane wrote: >> (But having said that, an alternate qualification name is something >> that could be implemented if there were any agreement on what to use.) > Would something like ARG.name be acceptable? It all depends on how likely you think it is that the function

Re: [HACKERS] named parameters in SQL functions

Tom Lane wrote: Robert Haas writes: On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote: Well, if the funcname.varname gadget will work, as you suggest elsewhere it could, I think that would suffice. I had assumed that was just something in the plpgsql engine. That gadget isn't horribly

Re: [HACKERS] Aggregate ORDER BY patch

Hitoshi Harada writes: > 2009/11/16 Andrew Gierth : > "Hitoshi" == Hitoshi Harada writes: >>>  Hitoshi>  - SortGroupClause.implicit >>>  Hitoshi> "implicit" member was added in SortGroupClause. I didn't >>>  Hitoshi> find clear reason to add this. Could you show a case to >>>  Hitoshi> clarify th

Re: [HACKERS] named parameters in SQL functions

Robert Haas writes: > On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote: >> Well, if the funcname.varname gadget will work, as you suggest elsewhere it >> could, I think that would suffice. I had assumed that was just something in >> the plpgsql engine. > That gadget isn't horribly convenien

Re: [HACKERS] Aggregate ORDER BY patch

2009/11/16 Andrew Gierth : >> "Hitoshi" == Hitoshi Harada writes: > >  Hitoshi> Questions here: >  Hitoshi> - agglevelsup? > What case exactly would you consider an error? When an order by > expression references a lower (more deeply nested) query level than > any of the actual arguments? It'

Re: [HACKERS] Python 3.1 support

On Nov 15, 2009, at 6:37 AM, Peter Eisentraut wrote: > but these two features don't excite me at all, hrm.. at all? I can see how function modules might look like a half-step backwards from function fragments at first, but the benefits of a *natural* initialization section (the module body) w

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan wrote: > Tom Lane wrote: >> >> Andrew Dunstan writes: >> >>> >>> At Tom's suggestion I am looking at allowing use of parameter names in >>> SQL functions instead of requiring use of $1 etc. That raises the question >>> of how we would disambiguate a

Re: [HACKERS] Patch committers

On Sun, Nov 15, 2009 at 8:08 PM, Bruce Momjian wrote: > Magnus Hagander wrote: >> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote: >> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander >> > wrote: >> >> How about we add specific feature(s) about tihs to the commitfest >> >> management tool? Li

Re: [HACKERS] named parameters in SQL functions

Tom Lane wrote: Andrew Dunstan writes: At Tom's suggestion I am looking at allowing use of parameter names in SQL functions instead of requiring use of $1 etc. That raises the question of how we would disambiguate a parameter name from a column name. Throw error if ambiguous. We

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Tom Lane wrote: Yeah, that is a real problem for new would-be contributors --- there simply isn't that much low-hanging fruit waiting for them, unless they focus on areas that no one else has taken much interest in; and even then there are few really small tasks.

Re: [HACKERS] Patch committers

Magnus Hagander wrote: > On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote: > > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander > > wrote: > >> How about we add specific feature(s) about tihs to the commitfest > >> management tool? Like the possibility to directly link a git > >> repo/branch wit

Re: [HACKERS] Aggregate ORDER BY patch

On Sun, Nov 15, 2009 at 11:23 PM, Andrew Gierth wrote: > Future performance enhancements (which I have no particular plans to > tackle) would involve having the planner consult the desired aggregate > orderings and estimating the cost of sorting as opposed to the cost of > producing a plan with th

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Sun, Nov 15, 2009 at 12:50:14AM +, Roger Leigh wrote: > On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote: > > Roger Leigh writes: > > > The side effect from this change is that some of the testsuite > > > expected data will need updating due to the extra pad spaces > > > > No, we a

Re: [HACKERS] Summary and Plan for Hot Standby

"David E. Wheeler" writes: > On Nov 15, 2009, at 2:17 PM, Tom Lane wrote: >> I agree with Heikki that it would be better not to commit as long as >> any clear showstoppers remain unresolved. > If ever there were an argument for topic branches, *this is it*. How so? They've got a perfectly good

Re: [HACKERS] Summary and Plan for Hot Standby

On Nov 15, 2009, at 2:17 PM, Tom Lane wrote: >> So I'm in favor of committing part of the HS code even if there are >> known failure conditions, as long as those conditions are well-defined. > > If we're thinking of committing something that is known broken, I would > want to have a clearly defin

Re: [HACKERS] Aggregate ORDER BY patch

> "Andrew" == Andrew Gierth writes: Andrew> Performance. Andrew> tuplesort_getdatum etc. seems to be substantially faster than Andrew> tuplesort_gettupleslot especially for the case where you're Andrew> sorting a pass-by-value datum such as an integer (since the Andrew> datum is then st

Re: [HACKERS] Summary and Plan for Hot Standby

On Nov 15, 2009, at 4:19 PM, Simon Riggs wrote: On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: Right now, I don't know which you consider to be the must-fix issues, hence the thr

Re: [HACKERS] Hot standby, overflowed snapshots, testing

On 11/15/09 2:25 AM PST, "Simon Riggs" wrote: > On Sat, 2009-11-14 at 08:43 -0800, Robert Hodges wrote: > >> I can help set up automated basic tests for hot standby using 1+1 setups on >> Amazon. I¹m already working on tests for warm standby for our commercial >> Tungsten implementation and ne

Re: [HACKERS] Listen / Notify rewrite

Simon Riggs writes: > On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote: >> You misunderstand the requirements. LISTEN notifications are *not* >> meant to survive a database crash, and never have been. However, >> so long as both client and server stay up, they must be reliable. >> If the client

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Brendan Jurd writes: > However, I'm not sure how productive the [E]asy marker can really be. > Items end up on the TODO generally because a) we couldn't settle on a > way forward, or b) nobody was keen to do it right away. There just > aren't many genuinely "easy" items in there, easy ones usuall

Re: [HACKERS] Listen / Notify rewrite

On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote: > >> 3. Every distinct notification is delivered. > >> Regarding performance, the slru-queue is not fsync-ed to disk > > > These two statements seem to be in oppo

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

2009/11/16 Tom Lane : > The real problem with the entry that George picked up on was that it was > misdescribed and mislabeled as easy because whoever put it in ignored > the fact that there was not a consensus to do a half-baked fix ... > this is a problem with a wiki TODO list :-( Wouldn't it be

Re: [HACKERS] Summary and Plan for Hot Standby

Josh Berkus writes: > So I'm in favor of committing part of the HS code even if there are > known failure conditions, as long as those conditions are well-defined. If we're thinking of committing something that is known broken, I would want to have a clearly defined and trust-inspiring escape str

Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

David Fetter writes: > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: >> Peter Eisentraut wrote: >>> /home/peter/commit-msg >> er, what? > I'm suspecting a misfired script somewhere. No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" ... I think I've ma

[HACKERS] proposal: using PQexecParams in psql (using variables as real params)

Hello I propose to add possibility to use psql variables as real query parameters. The goal of this proposal is simplification of creating psql based commands. Current using of psql variables based on substitution has large area of using, but has some risks. a) there are possible sql injection, b)

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Andrew Dunstan writes: > George Gensure wrote: >> This begs a bigger question: what's *really* easy or low barrier to >> entry for very light contributors like myself? > The TODO list at doesn't seem to > have a huge number or [E] items. Maybe we need a b

Re: [HACKERS] Listen / Notify rewrite

Simon Riggs writes: > On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote: >> 3. Every distinct notification is delivered. >> Regarding performance, the slru-queue is not fsync-ed to disk > These two statements seem to be in opposition. How do you know a > notification will be delivered if t

Re: [HACKERS] named parameters in SQL functions

Andrew Dunstan writes: > At Tom's suggestion I am looking at allowing use of parameter names in > SQL functions instead of requiring use of $1 etc. That raises the > question of how we would disambiguate a parameter name from a column > name. Throw error if ambiguous. We already resolved this

[HACKERS] CommitFest 2009-11 Closed; Initial assignments

With some lazy Sunday slack, the 2009-11 CommitFest is now officially closed. Due to a bumper crop of review volunteers, almost all patches are already assigned an initial reviewer. Here are the notable exceptions: SE-PostgreSQL/Lite: It's hard to find a reviewer willing to take on a patch

Re: [HACKERS] Writeable CTE patch

I wrote: Attached is the latest version of this patch. Here's that same patch in context diff format. Sorry for the noise. Regards, Marko Tiikkaja *** a/doc/src/sgml/queries.sgml --- b/doc/src/sgml/queries.sgml *** *** 1499,1505 SELECT 3, 'three'; SELECT select_list FRO

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: > >> Simon Riggs wrote: > >>> Right now, I don't know which you > >>> consider to be the must-fix issues, hence the thread. > >> Ok, could you tackle th

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> Right now, I don't know which you >>> consider to be the must-fix issues, hence the thread. >> Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the >> index pages after the

Re: [HACKERS] Summary and Plan for Hot Standby

On 11/15/09 12:58 PM, Simon Riggs wrote: > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> Right now, I don't know which you >>> consider to be the must-fix issues, hence the thread. >> Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the >>

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Right now, I don't know which you > > consider to be the must-fix issues, hence the thread. > > Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the > index pages after the last b-tree vacuum r

Re: [HACKERS] commitfest patch move unavailable

Robert Haas wrote: (Maybe I should automatically create a "Miscellaneous" topic when each new CF is added?) I'm surprised you're populating each one from scratch every time, that seems like duplicated effort begging to be automated. Couldn't you just come up with a stock list of the most comm

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > Right now, I don't know which you > consider to be the must-fix issues, hence the thread. Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the index pages after the last b-tree vacuum record? Thanks. -- Heikki Linnakangas EnterpriseDB http://www.ente

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 21:56 +0200, Heikki Linnakangas wrote: > If you actually want to help, can you please focus on fixing the > must-fix bugs we know about? We can then discuss which of the > remaining known issues we're willing to live with. I intend to work on all of the issues, so not sure w

Re: [HACKERS] Hot standby, race condition between recovery snapshot and commit

Simon Riggs wrote: > On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote: > >> Am I missing anything? > > Will review. Thanks! Please use the head of git branch, I already found one major oversight in what I posted that's fixed there... I should go to bed already. -- Heikki Linnakang

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 12:09 PM, Greg Stark wrote: > 1) Error messages which mention column names are supposed to quote the > column name to set it apart from the error string. This also > guarantees that weird column names are referenced correctly as "foo > bar" or "$foo" so the reference in the err

[HACKERS] Re: Hot standby, race condition between recovery snapshot and commit

On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote: > Am I missing anything? Will review. > I also experimented with including the running-xacts information in the > checkpoint record itself. That somehow feels more straightforward to me, > but it wasn't really any less code, and it wou

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: >>> The LSN doesn't help there, because when an itemid is marked as dead, the LSN is not updated. >>> I was thinking we

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 7:56 PM, Andrew Chernow wrote: >> The point is that $ is a perfectly valid SQL identifier character and >> $foo is a perfectly valid identifier. You can always quote any >> identifier (yes, after case smashing) so you would expect if $foo is a >> valid identifier then "$foo

Re: [HACKERS] Aggregate ORDER BY patch

> "Hitoshi" == Hitoshi Harada writes: Hitoshi> Questions here: Hitoshi> - agglevelsup? Hitoshi> We have aggregate capability that all arguments from upper Hitoshi> level query in downer level aggregate makes aggregate call Hitoshi> itself to upper level call, as a constant value in down

Re: [HACKERS] named parameters in SQL functions

The point is that $ is a perfectly valid SQL identifier character and $foo is a perfectly valid identifier. You can always quote any identifier (yes, after case smashing) so you would expect if $foo is a valid identifier then "$foo" would refer to the same identifier. This case already exists

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > You agree there should be two phases? I'm hesitant to say 'yes', because then you will harass me with "but you said that you would be OK with fixing X, Y, Z later! Why don't you commit already!". Of course there should be several phases! We've *already* punted a lot of stuff

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:35 AM, Greg Stark wrote: > I don't think SQL is the height of language design either. But trying > to turn it into another language piece by piece is not gong to make it > any nicer. I don't know of anyone suggesting such a thing. > A sigil here doesn't accomplish anything

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > > > >> The LSN doesn't help there, because when an itemid is marked as dead, > >> the LSN is not updated. > > > > I was thinking we could update the

Re: [HACKERS] named parameters in SQL functions

David E. Wheeler wrote: $foo should be killed off as a valid identifier, IMNSHO. It's only legal when quoted. Unquoted indetifiers can't begin with $. see scan.l: ident_start [A-Za-z\200-\377_] ident_cont [A-Za-z\200-\377_0-9\$] identifier

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 7:29 PM, Simon Riggs wrote: > You agree there should be two phases? > I don't understand this repeated suggestion of "phases". Nobody's every suggested that we would refuse to add new features to HS after the initial commit or the 8.5 release. Of course there should be lat

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler wrote: > On Nov 15, 2009, at 11:21 AM, Greg Stark wrote: > > > $foo should be killed off as a valid identifier, IMNSHO. > > But failing that, some other sigil would be most welcome. I don't think SQL is the height of language design either. But tr

Re: [HACKERS] ALTER ROLE/DATABASE RESET ALL versus security

Tom Lane wrote: > It looks to me like the code in AlterSetting() will allow an ordinary > user to blow away all settings for himself. Even those that are for > SUSET variables and were presumably set for him by a superuser. Isn't > this a security hole? I would expect that an unprivileged user s

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 20:37 +0200, Heikki Linnakangas wrote: > Robert Haas wrote: > > But a > > query getting canceled because it touches a lot of tables sounds more > > like a limitation than an outright bug, > > It's not that the query might get canceled. It will abort WAL recovery, > kill all

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:21 AM, Greg Stark wrote: > No, that's not the same. > > The point is that $ is a perfectly valid SQL identifier character and > $foo is a perfectly valid identifier. You can always quote any > identifier (yes, after case smashing) so you would expect if $foo is a > valid id

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler wrote: >> Moreover you would still have conflicts possible because sql can quote >> identifiers so people can have columns named "$foo". You would have a >> weird syntactic detail where "$foo" would mean something different >> than $foo even though

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > >> The LSN doesn't help there, because when an itemid is marked as dead, >> the LSN is not updated. > > I was thinking we could update the index block LSN without writing WAL > using the LSN of the heap block that

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Andrew Chernow : > >>> I like the special marker idea.  A '$' would be nice because its already >>> in >>> use for similar purposes, but I think that would lead to ambiguity with >>> dollar quoting. >> >> no, it should be safe (if you don't use for dollar quoting some like >> $variablena

Re: [HACKERS] named parameters in SQL functions

I like the special marker idea. A '$' would be nice because its already in use for similar purposes, but I think that would lead to ambiguity with dollar quoting. no, it should be safe (if you don't use for dollar quoting some like $variablename$) Actually, I was thinking of something like

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 10:54 AM, Greg Stark wrote: > I'm japh too -- but that doesn't mean grabbing one little aesthetic > from Perl without copying the whole concept behind it makes any sense. > Perl sigils are an important part of the language and are a basic part > of the syntax. They aren't just

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Greg Stark : > On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule > wrote: >>> Personally, I like $var, but @var would be okay, and @@var is acceptable. >>> But I'm JAPH, so my biases should be obvious. >> >> @var or @@var should be a break for people from MySQL. @var are r/w in >> MySQL

Re: [HACKERS] named parameters in SQL functions

2009/11/16 Andrew Dunstan : > At Tom's suggestion I am looking at allowing use of parameter names in SQL > functions instead of requiring use of $1 etc. That raises the question of > how we would disambiguate a parameter name from a column name. Essentially, > ISTM, we could use some special marker

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > The LSN doesn't help there, because when an itemid is marked as dead, > the LSN is not updated. I was thinking we could update the index block LSN without writing WAL using the LSN of the heap block that leads to the killed tuple. Pre

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler wrote: > Personally, I like $var, but @var would be okay, and @@var is acceptable. But > I'm JAPH, so my biases should be obvious. I'm japh too -- but that doesn't mean grabbing one little aesthetic from Perl without copying the whole concept be

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule wrote: >> Personally, I like $var, but @var would be okay, and @@var is acceptable. >> But I'm JAPH, so my biases should be obvious. > > @var or @@var should be a break for people from MySQL. @var are r/w in > MySQL and @@var are global in T-SQL. So

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 13:15 -0500, Robert Haas wrote: > I know Simon has said that he feels that the effort > to finish the HS and SR patches for 9/15 was somewhat of an artificial > deadline, but ISTM that with only 3 months remaining until the close > of the final CommitFest for this release, and

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

George Gensure wrote: This begs a bigger question: what's *really* easy or low barrier to entry for very light contributors like myself? - I've got time, I like the product, I need to know what's going to get you a win, I may not be gunning particularly for the feature myself. The TODO li

  1   2   >