I do?
BDR is proprietary software, so you should contact the vendor.
--
Vik Fearing
an index on my_table (fld_1, fld_2, fld_3, fld_4,
tran_date) if your dataset gets bigger.
This query is 100% Standard SQL, so it *should* work on other engines.
That doesn't mean it will, though.
--
Vik Fearing
te a rule and a function
> for this.
Use an INSTEAD OF trigger on the view unless it's a simple view in which
case it "just works".
--
Vik Fearing
On 03/03/2020 00:02, Don Seiler wrote:
> On Mon, Mar 2, 2020, 12:30 Vik Fearing wrote:
>
>> On 02/03/2020 18:09, Don Seiler wrote:
>>> The REAL reason for this is that I'm wondering if I created a NOT NULL
>>> check constraint with "NOT VALID
ps I
> should have just asked this in its own thread but I started diving into the
> query plan thing.
You cannot do this because NOT NULL isn't a real constraint (meaning it
does not appear in pg_constraint). There have been several attempts to
make it a real constraint over the years but so fa
re is
one: https://github.com/xocolatl/periods/
> Can a function, called by a trigger, determine what table it was called
> for?
Yes.
--
Vik Fearing
On 26/02/2020 10:27, Vik Fearing wrote:
> WITH
> u (invoice_number) AS (
> UPDATE invoice_numbers
> SET invoice_number = invoice_number + 1
> WHERE country = $1
> RETURNING invoice_number
> ),
> i (invoice_number) AS (
> INSERT INTO invoice_numbe
TABLE i;
You can just put that in an SQL function for convenience.
> Hope this is the right place to ask.
Yes, it is.
--
Vik Fearing
true if you frequently connect to other people's systems.
> Otherwise I
> don't think it adds any value as a default since a novice user isn't going
> to know what */!/? means. Maybe I'm missing something.
A novice user won't understand any of psql's meta commands, either.
> -1 from me.
Thank
was
requested.
Please answer +1 if you want or don't mind seeing transaction status by
default in psql or -1 if you would prefer to keep the current default.
Thanks!
+1 from me.
--
Vik Fearing
On 13/09/2019 17:19, Paul Jungwirth wrote:
> The SQL:2011 standard also has temporal primary keys, foreign keys,
> SELECTs, and UPDATE/DELETEs, and we're working on adding those too.
And here is a full implementation of all that:
https://github.com/xocolatl/periods/
It is packaged in both the
patch for ALTER TYPE if it has a chance of
being accepted.
--
Vik Fearing
On 01/08/18 18:36, Andres Freund wrote:
> It's really annoying to
> get a hard to kill ant-wraparound autovacuum on an insert only table,
> where it's the only thing that'll trigger the autovacuum.
Somebody should do something about that.
--
Vi
can read my blog post
> at https://osm_seattle.snowandsnow.us/articles/Partitioning-Postgresql/
Please consider adding your PostgreSQL-related posts to Planet.
https://planet.postgresql.org/add.html
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr
isn't a change in behavior, it's a
change in the description of existing behavior.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
psql and then \dx+ an_extension you
can see what queries psql uses to get the information. That should put
you well on your way to doing what you want.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
urceforge died:
https://en.wikipedia.org/wiki/SourceForge#Project_hijackings_and_bundled_malware
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
official; I'm not sure if
> we'll change the draft again in response to the current discussions.
Also I think official text should have its own page on the website,
rather than just be on the wiki. Hopefully that's already planned.
--
Vik Fearing +33 6
h that the second command
> (INSERT) could not function properly.
No. It's because your view's WHERE clause is being added to your INSERT
and of course nothing matches, so nothing gets inserted.
> That would fit with what I observe, but I’m not sure how I go about
> proving
EXPLAIN
19 matches
Mail list logo
