Hi Hackers,
On 12/1/19 4:45 AM, Michael Paquier wrote:
> For now I have moved the patch to
> next CF, waiting on author.
We have withdrawn this patch for now. The reason for this is, that we
had ideas on how to split it into multiple simpler independent patches,
that can be reviewed and committed
Hi Ibrar, Thomas and Robert,
On 8/2/19 11:00 PM, Ibrar Ahmed wrote:
> I have rebased the patch and currently reviewing the patch
> on master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012).
Thanks a lot for your effort. We are now trying to put again more work
and time in this patch.
We are grateful
Dear all,
we rebased our temporal normalization patch on top of
554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28.
On 9/7/18 1:02 PM, Peter Moser wrote:
> The syntax is
> SELECT * FROM (r NORMALIZE s USING() WITH(period_r, period_s)) c;
Please find all information about our dec
On 01/26/2018 07:55 AM, Peter Moser wrote:
We have now a new approach to plan and execute NORMALIZE as a special
join node of type NORMALIZE, an append-plan on the inner join path,
and a merge-join executor. For the latter, we would need to
extend nodeMergejoin.c with an point-in-range
On 06/26/2018 07:06 PM, Tom Lane wrote:
Also worth noting is that similar issues arise elsewhere, eg we now
have "procedures" vs "functions" in a single namespace. Let's not have
DROP TABLE acting in a way that's inconsistent with other parts of the
system.
I think, that
DROP ...
could sea
On 06/26/2018 05:34 PM, Pavel Stehule wrote:
2018-06-26 17:23 GMT+02:00 Peter Moser <mailto:pitiz...@gmail.com>>:
What do you think, is it worth to create a patch to solve this
issue, where a DROP TABLE does not fail, if the given name is
actually a VIEW or vice-versa?
D
Hi,
I want to delete a table X, that may not exist, hence I execute
DROP TABLE IF EXISTS X;
However, if X is a view, I get an error
ERROR: "X" is not a table
HINT: Use DROP VIEW to remove a view.
SQL state: 42809
That is unexpected and also difficult to handle,
On Mon, 2018-01-08 at 11:18 -0500, Robert Haas wrote:
> I also don't agree with the idea that we should reject syntax that
> doesn't appear in the SQL standard. We have a great deal of such
> syntax already, and we add more of it in every release, and a good
> deal of it is contributed by you and
On Sun, 2018-01-07 at 09:58 +, Simon Riggs wrote:
> > The attached README explains the ALIGN operation step-by-step with
> > a TEMPORAL LEFT OUTER JOIN example. That is, we start from a query
> > input, show how we rewrite it during parser stage, and show how the
> > final execution generates r
On Sat, 2018-01-06 at 20:29 +, Simon Riggs wrote:
> * various PostJoinSetProjection() functions to be called as needed
> So the idea is we enable Postgres to allow major new functionality,
> as was done for PostGIS so successfully.
If we use a post-join approach many intermediate result tuples
On Thu, 2017-11-30 at 12:26 -0500, Robert Haas wrote:
> I wonder if we could instead think about R NORMALIZE S ON R.x = S.y
> WITH (R.time, S.time) as an ordinary join on R.x = S.y with some
> extra processing afterwards. After finding all the join partners for
> a row in R, extract all the lower
2017-11-14 18:42 GMT+01:00 Tom Lane :
> You might consider putting the rewriting into, um, the rewriter.
> It could be a separate pass after view expansion, if direct integration
> with the existing behavior seems unduly spaghetti-ish. Or do it in
> an early phase of planning as he suggested. The
2017-11-14 18:42 GMT+01:00 Tom Lane :
> Robert is correct that putting this into the parser is completely the
> wrong thing. If you do that, then for example views using the features
> will reverse-list in the rewritten form, which we Do Not Want, even
> if the rewritten form is completely valid S
2017-11-11 13:19 GMT+01:00 Robert Haas :
> This is really good input. If the feature weren't useful, then it
> wouldn't make sense to try to figure out how to integrate it, but if
> it is, then we should try.
We are happy to hear this and will do the implementation. Any input
regarding the imple
2017-10-06 19:22 GMT+02:00 Paul A Jungwirth :
> I just wanted to chime in and say that the work these people have done
> is *amazing*. I read two of their papers yesterday [1, 2], and if you
> are interested in temporal data, I encourage you to read them too. The
> first one is only 12 pages and qu
15 matches
Mail list logo
