> On 30 Nov 2023, at 02:39, Kyotaro Horiguchi wrote:
> In the bleeding-edge version of pg_dump, when a conditionspecifying an
> index, for example, is described in an object filter file, the
> following message is output. However, there is a period at the end of
> the line. Shouldn't this be
Sorry for the sequential mails.
In the bleeding-edge version of pg_dump, when a conditionspecifying an
index, for example, is described in an object filter file, the
following message is output. However, there is a period at the end of
the line. Shouldn't this be removed?
$ pg_dump
Hi,
I'm sending this to pgsql-hackers because Vik Fearing (xocolatl), the reviewer
of https://commitfest.postgresql.org/30/2316 also has a repository with a pgsql
implementation of said functionalities: https://github.com/xocolatl/periods.
I have stumbled upon a probable issue
(https
On Thu, Jul 15, 2021 at 6:21 AM Ibrar Ahmed wrote:
> Based on last comments of Paul and David S I am changing the status to
> "Waiting on Author".
I thought the subject was quite out of date, so I sent my last patch
here:
On Fri, Apr 9, 2021 at 4:54 PM David Steele wrote:
> On 4/8/21 7:40 PM, Paul A Jungwirth wrote:
> > On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
> >>
> >> Paul, you can submit to the next CF when you are ready with a new patch.
> >
> > Thanks David! I've made a lot of progress but still
On 4/8/21 7:40 PM, Paul A Jungwirth wrote:
On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
Paul, you can submit to the next CF when you are ready with a new patch.
Thanks David! I've made a lot of progress but still need to finish
support for CASCADE on temporal foreign keys. I've been
On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
>
> Paul, you can submit to the next CF when you are ready with a new patch.
Thanks David! I've made a lot of progress but still need to finish
support for CASCADE on temporal foreign keys. I've been swamped with
other things, but hopefully I
had a chance to focus on it for a while, but I'm hoping
to make some improvements over the coming holidays, especially based on
feedback from my talk at PgCon. There are a handful of small specific
things I'd like to do, and then one big thing: add support for PERIODs.
Vik said I could include
, but I'm hoping
to make some improvements over the coming holidays, especially based on
feedback from my talk at PgCon. There are a handful of small specific
things I'd like to do, and then one big thing: add support for PERIODs.
Vik said I could include his old patch for PERIODs, so I'd like to get
On Thu, Sep 17, 2020 at 04:51:01PM +0900, Michael Paquier wrote:
> This patch had no reviews, unfortunately it cannot be applied
> cleanly. Could you send a rebase please?
This had no replies after two weeks, so I have marked the patch as
RwF. Please feel free to resubmit if you are planning to
On Wed, Mar 11, 2020 at 04:27:53PM -0700, Paul A Jungwirth wrote:
> Here is a patch rebasing on master (meant to be applied on top of my
> other multirange patch) and newly including UPDATE/DELETE FOR PORTION
> OF. FOR PORTION OF works on any table with a temporal primary key. It
> restricts the
On Mon, Nov 11, 2019 at 12:13:20PM -0800, Paul A Jungwirth wrote:
> I could use some guidance on where in the query-processing pipeline I
> should implement some things here. Basically if you say
> [...]
Paul, please be careful to update correctly the entry of the patch in
the CF app. This was
not, and we need a way of knowing which is which. And
then supporting PERIODs requires a little extra "magic" beyond that.
But if someone has a great idea I'm open to hearing about it. :-)
Thanks,
Paul
link is ostensibly an annotated bibliography but really tells a
> story about how the research has developed:
>
>
> https://illuminatedcomputing.com/posts/2017/12/temporal-databases-bibliography/
>
> - There is also some discussion about PERIODs vs ranges upthread here,
> as wel
gwir/postgres-temporal-talk
- This link is ostensibly an annotated bibliography but really tells a
story about how the research has developed:
https://illuminatedcomputing.com/posts/2017/12/temporal-databases-bibliography/
- There is also some discussion about PERIODs vs ranges upthread here,
as
B, DB2,
> Oracle, and MS SQL Server:
>
> https://illuminatedcomputing.com/posts/2019/08/sql2011-survey/
>
> A few highlights are:
>
> - Everyone lets you define PERIODs, but what you can do with them is
> still *very* limited.
> - No one treats PERIODs as first-class
1 while still supporting Postgres range types, I wrote an
article that surveys SQL:2011 temporal features in MariaDB, DB2,
Oracle, and MS SQL Server:
https://illuminatedcomputing.com/posts/2019/08/sql2011-survey/
A few highlights are:
- Everyone lets you define PERIODs, but what you can do with them
The patch does not work.
postgres=# CREATE TABLE foo (id int,r int4range, valid_at tsrange, CONSTRAINT
bar_pk PRIMARY KEY (r, valid_at WITHOUT OVERLAPS));
CREATE TABLE
postgres=# CREATE TABLE bar (id int,r int4range, valid_at tsrange, CONSTRAINT
bar_fk FOREIGN KEY (r, PERIOD valid_at)
On Wed, Jul 31, 2019 at 1:01 AM Ibrar Ahmed wrote:
> I have rebased the patch to master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012)
> and fixed some compilation warning. Now I am reviewing the actual code.
Thanks for doing that Ibrar. I think the right status for this CF
entry is now: Needs
Hi Paul,
I have rebased the patch to master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012)
and fixed some compilation warning. Now I am reviewing the actual code.
On Fri, Jul 26, 2019 at 6:35 PM Ibrar Ahmed wrote:
> The patch requires to rebase on the master branch.
>
> The new status of this
The patch requires to rebase on the master branch.
The new status of this patch is: Waiting on Author
work over to an
extension. It looks like you've made a lot of progress! I'd be eager
to work with you on getting this into core.
Alvaro: it's a mix of orthogonal and not orthogonal. :-) My work lets
you use range types directly in SQL:2011 constructs, whereas Vik's
work lets you use SQL:2011 PERIODs
Hello Vik, Paul,
On 2019-Jul-04, Vik Fearing wrote:
> I've been working on this as an extension instead. It allows me to do some
> stuff in plpgsql which is much easier for me.
>
> https://github.com/xocolatl/periods/
Hmm, okay.
> I would love to have all this in core (e
On Thursday, July 4, 2019 8:04 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
> Hello Vik,
> On 2018-Jun-05, Vik Fearing wrote:
>
>>> I understand that your patch is just to allow defining periods, but I
>>> thought I'd share my own hopes earlier rather than later
Hello Vik,
On 2018-Jun-05, Vik Fearing wrote:
> > I understand that your patch is just to allow defining periods, but I
> > thought I'd share my own hopes earlier rather than later, in case you
> > are doing more work on this.
>
> Yes, I plan on doing much mor
Hi Pail,
On 3/10/19 2:41 AM, Paul A Jungwirth wrote:
On Tue, Mar 5, 2019 at 12:35 AM David Steele wrote:
I have marked this patch as targeting PG13 since it is clearly not
material for PG12. I also added you as the patch author.
Thanks David! Targeting PG13 was my intention, so sorry if I
On Tue, Mar 5, 2019 at 12:35 AM David Steele wrote:
> I have marked this patch as targeting PG13 since it is clearly not
> material for PG12. I also added you as the patch author.
Thanks David! Targeting PG13 was my intention, so sorry if I messed up
the commitfest entry.
Here is a new patch
Hi Paul,
On 11/24/18 4:55 AM, Paul A Jungwirth wrote:
On Fri, Nov 23, 2018 at 3:41 PM Paul A Jungwirth
wrote:
Here is a patch for my progress on this so far.
Well this is embarrassing, but my last patch used the mistaken syntax
`PRIMARY KEY (cols, WITHOUT OVERLAPS col)`. Here is a new patch
On Fri, Nov 23, 2018 at 3:41 PM Paul A Jungwirth
wrote:
> Here is a patch for my progress on this so far.
Well this is embarrassing, but my last patch used the mistaken syntax
`PRIMARY KEY (cols, WITHOUT OVERLAPS col)`. Here is a new patch which
uses the correct syntax `PRIMARY KEY (cols, col
you say `CONSTRAINT foo PRIMARY KEY (cols, WITHOUT
OVERLAPS some_range_col)`, both in `CREATE TABLE` and `ALTER TABLE`.
It doesn't support foreign keys yet, and it only supports range
columns, not PERIODs. (I'm starting to realize that adding PERIODs
will be a lot of work, although I'm still up
Hi Jeff,
Thanks for sharing your thoughts and encouragement! :-)
> The model in [7] is
> based heavily on pack/unpack operators, and it's hard for me to see
> how those fit into SQL. Also, the pack/unpack operators have some
> theoretical weirdness that the book does not make clear*.
>
> *: My
deas in [7].
> > ...
> > [7] C. J. Date, Hugh Darwen, Nikos Lorentzos. Time and Relational
> > Theory, Second Edition: Temporal Databases in the Relational Model
> > and
> > SQL. 2nd edition, 2014.
>
> +1 on this approach. I think [7] got the model right. If w
ranges, and then use those to
> > > implement PERIOD-based features.
> > +1 on this approach. I think [7] got the model right. If we can
> > implement SQL-standard PERIODs on top of it, then that's a bonus, but
> > having sane, flexible, coherent set of range operators is more importa
we can
> implement SQL-standard PERIODs on top of it, then that's a bonus, but
> having sane, flexible, coherent set of range operators is more important
> to me.
Okay, I'm surprised to hear from you and Isaac that following the
standard isn't as important as I thought, but I'm ce
, 2014.
+1 on this approach. I think [7] got the model right. If we can
implement SQL-standard PERIODs on top of it, then that's a bonus, but
having sane, flexible, coherent set of range operators is more important
to me.
What are we missing? It's been years since I read that book, but IIRC
On Sun, 21 Oct 2018 at 14:18, Paul A Jungwirth
wrote:
> Also, just how strictly do we have to follow the standard? Requiring
> sentinels like '01 JAN 3000` just seems so silly. Could Postgres
> permit nullable start/end PERIOD columns, and give them the same
> meaning as ranges (unbounded)? Even
] for these things.
In SQL:2011, temporal features all build upon PERIODs, which are a new
concept you can attach to tables. Each PERIOD is composed of a start
column and an end column (both of some date/time type). You define
PERIODs when you CREATE TABLE or ALTER TABLE. Then you refer
ame thing as our range types except there is no new
>> storage. I believe if Jeff Davis had given us range types a few years later
>> than he did, it would have been using periods.
>
> Hi Vik, I'm really glad to see someone working on temporal features!
> I've only dab
On Tue, Jun 5, 2018 at 12:47 PM, Paul A Jungwirth
wrote:
> Also, this may not be very helpful, but I started an extension to
> support temporal foreign keys here:
>
> https://github.com/pjungwir/time_for_keys
>
> It uses intervals, not periods, but maybe you can steal some ide
iven us range types a few
> years later than he did, it would have been using periods.
>
> Attached is a WIP patch that I have been working on. The only thing left
> is completing periods on inherited tables, and finishing up pg_dump. I'm
> posting this now just to make sure my basic
SQL:2011 introduced the concept of a "period". It takes two existing columns
and basically does the same thing as our range types except there is no new
storage. I believe if Jeff Davis had given us range types a few years later
than he did, it would have been using periods.
Attache
41 matches
Mail list logo
