> 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 remo
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 --filter=/tmp/
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
(
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:
https://www.postgresql.org/message-id/CA%2BrenyUApHgSZF9-nd-a0%2BOPGharLQ
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 ne
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 sw
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 can
ven't 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
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 his old patch for PERIODs
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 UP
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 ma
OR PORTION OF, sometimes we need to do the extra things
and sometimes 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
t;
> - 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 he
github.com/pjungwir/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 upthrea
l 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 is
> still *very* limited.
> - No one treats PERIODs as
o conform to
SQL:2011 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
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) REFERENCES
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 rev
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 patc
The patch requires to rebase on the master branch.
The new status of this patch is: Waiting on Author
d your 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
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 co
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
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 more
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 m
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 re
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 WIT
This patch lets 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, alt
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 q
the ideas 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.
nges, 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 im
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, bu
ition, 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
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
tandard [1] 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 re
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'v
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
ars 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 dabbled in Postgres hacking, but I've been following
temporal database research for several years, so I hope you won't mind
my commen
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 foundation is sound, and to let
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
42 matches
Mail list logo
