[HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Hi Abhijit - > What's the status of this patch? The latest version of the patch needs a review, and I'd like to get it committed in this CF if possible. Thanks - Nick -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Thanks for the detailed feedback, I'm sorry it took so long to
incorporate it. I've attached the latest version of the patch, fixing
in particular:
> We have this block:
I've re-written this so it only does a single pass through the window
definitions (my patch originally added a second pass), and only does
the clone if required.
> In gram.y there are some spurious whitespaces at end-of-line.
Fixed - I didn't know about diff --check, it's very useful!
> Also, in parsenodes.h, you had the [MANDATORY] and such tags.
I've re-written the comments (without tags) to make it much easier to
understand . I agree they were ugly!
>Exactly what case does the "in this case" phrase refer to?
Clarified in the comments
>A style issue. You have this:
Fixed
> And a final style comment.
Fixed
> Finally, I'm not really sure about the column you added to the regression
> tests table.
Indeed, it was a bit artificial. I've re-written the tests to use a
separate table as you suggest.
Thanks -
Nick
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0809a6d..5da852e 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -13185,6 +13185,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
lag(value any
[, offset integer
[, default any ]])
+ [ { RESPECT | IGNORE } NULLS ]
@@ -13199,7 +13200,9 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
default are evaluated
with respect to the current row. If omitted,
offset defaults to 1 and
- default to null
+ default to null. If
+ IGNORE NULLS is specified then the function will be evaluated
+ as if the rows containing nulls didn't exist.
@@ -13212,6 +13215,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
lead(value any
[, offset integer
[, default any ]])
+ [ { RESPECT | IGNORE } NULLS ]
@@ -13226,7 +13230,9 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
default are evaluated
with respect to the current row. If omitted,
offset defaults to 1 and
- default to null
+ default to null. If
+ IGNORE NULLS is specified then the function will be evaluated
+ as if the rows containing nulls didn't exist.
@@ -13320,11 +13326,10 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
The SQL standard defines a RESPECT NULLS or
-IGNORE NULLS option for lead, lag,
-first_value, last_value, and
-nth_value. This is not implemented in
-PostgreSQL: the behavior is always the
-same as the standard's default, namely RESPECT NULLS.
+IGNORE NULLS option for first_value,
+last_value, and nth_value. This is not
+implemented in PostgreSQL: the behavior is
+always the same as the standard's default, namely RESPECT NULLS.
Likewise, the standard's FROM FIRST or FROM LAST
option for nth_value is not implemented: only the
default FROM FIRST behavior is supported. (You can achieve
diff --git a/src/backend/executor/nodeWindowAgg.c b/src/backend/executor/nodeWindowAgg.c
index 2fcc630..5cea825 100644
--- a/src/backend/executor/nodeWindowAgg.c
+++ b/src/backend/executor/nodeWindowAgg.c
@@ -2431,7 +2431,6 @@ window_gettupleslot(WindowObject winobj, int64 pos, TupleTableSlot *slot)
* API exposed to window functions
***/
-
/*
* WinGetPartitionLocalMemory
* Get working memory that lives till end of partition processing
@@ -2467,6 +2466,17 @@ WinGetCurrentPosition(WindowObject winobj)
}
/*
+ * WinGetFrameOptions
+ * Returns the frame option flags
+ */
+int
+WinGetFrameOptions(WindowObject winobj)
+{
+ Assert(WindowObjectIsValid(winobj));
+ return winobj->winstate->frameOptions;
+}
+
+/*
* WinGetPartitionRowCount
* Return total number of rows contained in the current partition.
*
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 7b9895d..f11bc66 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -290,6 +290,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
%type TriggerEvents TriggerOneEvent
%type TriggerFuncArg
%type TriggerWhen
+%type opt_ignore_nulls
%type event_trigger_when_list event_trigger_value_list
%type event_trigger_when_item
@@ -552,7 +553,7 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
HANDLER HAVING HEADER_P HOLD HOUR_P
- IDENTITY_P IF_P ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IN_P
+ IDENTITY_P IF_P IGNORE ILIKE IMMEDIATE IMMUTABLE IMPLICIT_P IN_P
INCLUDING INCREMENT INDEX INDEXES INHERIT INHERITS INITIALLY INLINE_P
INNER_P INOUT INPUT_P INSENSITIVE INSERT INSTEAD INT_P INTEGER
INTERSECT INTERVAL INTO INVOKER IS IS
Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> bms_add_member() is an accident waiting to happen I've attached a patch that makes it use repalloc as suggested - is it OK to commit separately? I'll address the lead-lag patch comments in the next couple of days. Thanks - repalloc.patch Description: Binary data -- 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] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> Please fix these compiler warnings Fixed - see attached. Thanks - lead-lag-ignore-nulls.patch Description: Binary data -- 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] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> but needs a rebase. See attached - thanks! lead-lag-ignore-nulls.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
np, optimising for quality not speed :) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
I've attached a revised version that fixes the issues above: > changing a reference of the form: > OVER w > into: > OVER (w) Fixed (and I've updated the tests). > It's bad form to modify a list while iterating through it. Fixed > We shouldn't create an arbitrary number of duplicate windows Fixed > Is there a problem with having two windowdefs in > the p_windowdefs list with the same name > ... > You'll have to be a little careful that any other code knows that names > can be duplicated in the list though. I'm not sure I really can verify this - as I'm not sure how much contrib / other third-party code has access to this data structure. I'd prefer to be cautious and just create a child window if needed. > I think we should get rid of the bitmapset entirely > ... > Instead of the bitmapset, we can keep track of two offsets I've modified leadlag_common so it uses your suggested algorithm for constant offsets (although it turns out you only need to keep a single int64 index in the context). This algorithm calls WinGetFuncArgInPartition at least twice per row, once to check whether the current row is null (and so check if we have to move the leading / lagged index forward) and either once to get leading / lagging value or more than once to push the leading / lagged value forwards to the next non-null value. I've kept the bitmap solution for the non-constant offset case (i.e. the random partition access case) as I believe it changes the cost of calculating the lead / lagged values for every row in the partition to O(partition size) - whereas a non-caching scan-the-partition solution would be O(partition size * partition size). Is that OK? Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> pg_get_viewdef() needs to be updated Ah, good catch - I've fixed this in the attached. I also discovered that there's a parent-child hierarchy of WindowDefs (using relname->name), so instead of cloning the WindowDef (in parse_agg.c) if the frameOptions are different (e.g. by adding the ignore-nulls flag) I create a child of the WindowDef and override the frameOptions. This has the useful side-effect of making pg_get_viewdef work as expected (the previous iteration of the patch produced a copy of the window definintion, not the window name, as it was using a nameless clone), although the output has parentheses around the view name: > lag(i.i, 2) IGNORE NULLS OVER (w) AS lagged_by_2 I've updated the test cases accordingly. Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
I've attached another iteration of the patch that fixes the multiple-window bug and adds (& uses) a function to create a Bitmapset using a custom allocator. I don't think there's any outstanding problems with it now. > Alternatively, it might be trivial to make all aggregate functions work with ignore nulls in a window context This is a good idea, but I'd like to keep the scope of this patch limited for the time being - I'll look at doing this (along with the first / last / nth value window functions) for a later release. Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> this should throw a FEATURE_NOT_SUPPORTED error if it is used for window functions that don't support it > arbitrary aggregate functions over a window ... should also throw a FEATURE_NOT_SUPPORTED error. Fixed (with test cases) in the attached patch. > because the same window may be shared by multiple window function calls. Ah, your example gives the stack trace below. As the respect / ignore nulls frame option is part of the window definition your example should cause two windows to be created (both based on w, but one with the respect-nulls flag set), but instead it fails an assert as one window definition can't have two sets of frame options. It might take me a day or two to solve this - let me know if this approach (making the parser create two window objects) seems wrong. #2 0x000100cdb68b in ExceptionalCondition (conditionName=Could not find the frame base for "ExceptionalCondition". ) at /Users/xxx/postgresql/src/backend/utils/error/assert.c:54 #3 0x0001009a3c03 in transformWindowFuncCall (pstate=0x7f88228362c8, wfunc=0x7f8822948ec0, windef=0x7f88228353a8) at /Users/xxx/postgresql/src/backend/parser/parse_agg.c:573 Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
I've fixed the problems you mentioned (see attached) - sorry, I was a bit careless with the docs. > + null_values = (Bitmapset *) WinGetPartitionLocalMemory( > + winobj, > + BITMAPSET_SIZE(words_needed)); > + Assert(null_values); > > This certainly seems ugly - isn't there a way to accomplish this > without having to violate the Bitmapset abstraction? Indeed, it's ugly. I've revised it slightly to: > null_values = (Bitmapset *) WinGetPartitionLocalMemory( >winobj, >BITMAPSET_SIZE(words_needed)); > null_values->nwords = (int) words_needed; ...which gives a proper bitmap. It's hard to break this into a factory method like bms_make_singleton as I'm getting the (zero'ed) partition local memory from one call, then forcing a correct bitmap's structure on it. Maybe bitmapset.h needs an bms_initialise(void *, int num_words) factory method? You'd still have to use the BITMAPSET_SIZE macro to get the correct amount of memory for the void*. Maybe the factory method could take a function pointer that would allocate memory of the given size (e.g. Bitmapset* initialize(void* (allocator)(Size_t), int num_words) ) - this means I could still use the partition's local memory. I don't think the solution would be tidier if I re-instated the leadlag_context struct with a single Bitmapset member. Other Bitmapset usage seems to just call bms_make_singleton then bms_add_member over and over again - which afaict will call palloc every BITS_PER_BITMAPWORD calls, which is not really what I want. Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> This patch will need to be rebased over those changes See attached - lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> The result of the current patch using lead Actually, I think I agree with you (and, FWIW, so does Oracle: http://docs.oracle.com/cd/E11882_01/server.112/e25554/analysis.htm#autoId18). I've refactored the window function's implementation so that (e.g.) lead(5) means the 5th non-null value away in front of the current row (the previous implementation was the last non-null value returned if the 5th rows in front was null). These semantics are slower, as the require the function to scan through the tuples discarding non-null ones. I've made the implementation use a bitmap in the partition context to cache whether or not a given tuple produces a null. This seems correct (it passes the regression tests) but as it stores row offsets (which are int64s) I was careful not to use bitmap methods that use ints to refer to set members. I've added more explanation in the code's comments. Thanks - lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
OK - I've attached another iteration of the patch with Troels' grammar changes. I think the only issue remaining is what the standard says about lead semantics. Thanks - lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Good catch - I've attached a patch to address your point 1. It now returns the below (i.e. correctly doesn't fill in the saved value if the index is out of the window. However, I'm not sure whether (e.g.) lead-2-ignore-nulls means count forwards two rows, and if that's null use the last one you've seen (the current implementation) or count forwards two non-null rows (as you suggest). The behaviour isn't specified in a (free) draft of the 2003 standard (http://www.wiscorp.com/sql_2003_standard.zip), and I don't have access to the (non-free) final version. Could someone who does have access to it clarify this? I've also added your example to the regression test cases. select val, lead(val, 2) ignore nulls over (order by id) from test_table; val | lead -+-- 1 |3 2 |4 3 |4 4 |4 |4 |5 |6 5 |7 6 | 7 | (10 rows) If the other reviewers are happy with your grammar changes then I'll merge them into the patch. Alternatively, if departing from the standard is OK then we could reorder the keywords so that a window function is like SELECT lag(x,1) OVER RESPECT NULLS (ORDER BY y) - i.e. putting the respect / ignore tokens after the OVER reserved keyword. Although non-standard it'd make the grammar change trivial. > Also, I think someone mentioned this already, but what about > first_value() and last_value()? Shouldn't we do those at the same time? I didn't include this functionality for the first / last value window functions as their implementation is currently a bit different; they just call WinGetFuncArgInFrame to pick out a single value. Making these functions respect nulls would involve changing the single lookup to a walk through the tuples to find the first non-null version, and keeping track of this index in a struct in the context. As this change is reasonably orthogonal I was going to submit it as a separate patch. Thanks - lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Thanks for the reviews. I've attached a revised patch that has the lexer refactoring Alvaro mentions (arbitarily using a goto rather than a bool flag) and uses Jeff's idea of just storing the index of the last non-null value (if there is one) in the window function's context (and not the Datum itself). However, Robert's right that SELECT ... ORDER BY respect NULLS LAST will now fail. An earlier iteration of the patch had RESPECT and IGNORE as reserved, but that would have broken tables with columns called "respect" (etc.), which the current version allows. Is this backwards incompatibility acceptable? If not, maybe I should try doing a two-token lookahead in the token-aggregating code between the lexer and the parser (i.e. make a RESPECT_NULLS token out of a sequence of RESPECT NULLS OVER tokens, remembering to replace the OVER token)? Or what about adding an %expect statement to the Bison grammar, confirming that the shift / reduce conflicts caused by using the RESPECT, IGNORE & NULL_P tokens the in out_clause rule are OK? Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Thanks for the feedback. For the parsing changes, it seems I can either make RESPECT and IGNORE reserved keywords, or add a lookahead to construct synthetic RESPECT NULLS and IGNORE NULLS keywords. The grammar wouldn't compile if RESPECT and IGNORE were just normal unreserved keywords due to ambiguities after a function definition (e.g. select abs(1) respect; - which is currently a valid statement). I've redone the leadlag function changes to use datumCopy as you suggested. However, I've had to remove the NOT_USED #ifdef around datumFree so I can use it to avoid building up large numbers of copies of Datums in the memory context while a query is executing. I've attached the revised patch... Thanks - Nick On 24 March 2013 03:43, Hitoshi Harada wrote: > > > On Sat, Mar 23, 2013 at 3:25 PM, Nicholas White wrote: > >> Thanks - I've added it here: >> https://commitfest.postgresql.org/action/patch_view?id=1096 . >> >> I've also attached a revised version that makes IGNORE and RESPECT >> UNRESERVED keywords (following the pattern of NULLS_FIRST and NULLS_LAST). >> > > Hm, you made another lookahead in base_yylex to make them unreserved -- > looks ok, but not sure if there was no way to do it. > > You might want to try byref types such as text. It seems you need to copy > the datum to save the value in appropriate memory context. Also, try to > create a view on those expressions. I don't think it correctly preserves > it. > > Thanks, > -- > Hitoshi Harada lead-lag-ignore-nulls.patch Description: Binary data -- 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] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Thanks - I've added it here: https://commitfest.postgresql.org/action/patch_view?id=1096 . I've also attached a revised version that makes IGNORE and RESPECT UNRESERVED keywords (following the pattern of NULLS_FIRST and NULLS_LAST). Nick On 23 March 2013 14:34, Tom Lane wrote: > Nicholas White writes: > > The SQL standard defines a RESPECT NULLS or IGNORE NULLS option for lead, > > lag, [...]. This is not implemented in PostgreSQL > > (http://www.postgresql.org/docs/devel/static/functions-window.html) > > I've had a go at implementing this, and I've attached the resulting > patch. > > It's not finished yet, but I was hoping to find out if my solution is > along > > the right lines. > > Since we're trying to get 9.3 to closure, this patch probably isn't > going to get much attention until the 9.4 development cycle starts > (in a couple of months, likely). In the meantime, please add it to > the next commitfest list so we remember to come back to it: > https://commitfest.postgresql.org/action/commitfest_view?id=18 > > One comment just from a quick eyeball look is that we really hate > adding new keywords that aren't UNRESERVED, because that risks > breaking existing applications. Please see if you can refactor the > grammar to make those new entries unreserved. > > regards, tom lane > lead-lag-ignore-nulls.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> The SQL standard defines a RESPECT NULLS or IGNORE NULLS option for lead, lag, [...]. This is not implemented in PostgreSQL (http://www.postgresql.org/docs/devel/static/functions-window.html) I've had a go at implementing this, and I've attached the resulting patch. It's not finished yet, but I was hoping to find out if my solution is along the right lines. In particular, I'm storing the ignore-nulls flag in the frameOptions of a window function definition, and am adding a function to the windowapi.h to get at these options. I'm keeping the last non-null value in WinGetPartitionLocalMemory (which I hope is the right place), but I'm not using any of the *GetDatum macros to access it. An example of my change's behaviour: nwhite=# select *, lag(num,0) ignore nulls over (order by generate_series) from nwhite-# (select generate_series from generate_series(0,10)) s nwhite-# left outer join nwhite-# numbers n nwhite-# on (s.generate_series = n.num); generate_series | num | lag -+-+- 0 | | 1 | 1 | 1 2 | | 1 3 | | 1 4 | 4 | 4 5 | 5 | 5 6 | | 5 7 | | 5 8 | | 5 9 | 9 | 9 10 | | 9 (11 rows) I'd find this feature really useful, so I hope you can help me get my patch to a contributable state. Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
> The SQL standard defines a RESPECT NULLS or IGNORE NULLS option for lead, lag, [...]. This is not implemented in PostgreSQL (http://www.postgresql.org/docs/devel/static/functions-window.html) I've had a go at implementing this, and I've attached the resulting patch. It's not finished yet (there's no documentation and no tests for a start), but I was hoping to find out if my solution is along the right lines. In particular, I'm storing the ignore-nulls flag in the frameOptions of a window function definition, and am adding a function to the windowapi.h to get at these options. I'm keeping the last non-null value in WinGetPartitionLocalMemory (which I hope is the right place), but I'm not using any of the *GetDatum macros to access it. An example of my change's behaviour: nwhite=# select *, lag(num,0) ignore nulls over (order by generate_series) from nwhite-# (select generate_series from generate_series(0,10)) s nwhite-# left outer join nwhite-# numbers n nwhite-# on (s.generate_series = n.num); generate_series | num | lag -+-+- 0 | | 1 | 1 | 1 2 | | 1 3 | | 1 4 | 4 | 4 5 | 5 | 5 6 | | 5 7 | | 5 8 | | 5 9 | 9 | 9 10 | | 9 (11 rows) I'd find this feature really useful, so I hope you can help me get my patch to a contributable state. Thanks - Nick lead-lag-ignore-nulls.patch Description: Binary data -- 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] S_ISLNK
Ah - OK. It turns out I'd run ./configure in the postgresql directory before running it in my build directory, so I had two (different) pg_config.hs! The below builds for me from a clean source tree now. Thanks - Nick ./path/to/build/configure CC=x86_64-w64-mingw32-gcc --target=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --without-readline --without-zlib --disable-thread-safety On 14 November 2012 06:25, Tom Lane wrote: > Nicholas White writes: >> Hi - I'm cross-compiling the master branch (cygwin/mingw) and have found a >> reference to S_ISLNK that isn't guarded by #ifndef WIN32 like the ones in >> basebackup.c are. > > That whole function is guarded by HAVE_READLINK, so I'm not seeing the > problem (and neither are the Windows members of the buildfarm). What > environment are you in that has readlink() and not S_ISLNK? > > 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
[HACKERS] S_ISLNK
Hi - I'm cross-compiling the master branch (cygwin/mingw) and have found a reference to S_ISLNK that isn't guarded by #ifndef WIN32 like the ones in basebackup.c are. Could you merge the attached fix? Thanks - Nick exec-symlink-ifdef.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
