+RoleId:CURRENT_USER{ $$ =
current_user;}
+ | USER { $$ = current_user;}
+ | CURRENT_ROLE { $$ = current_user;}
+ | SESSION_USER { $$ =
On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this series.
Here is some input on patch 4:
1) Use of OBJECT_ATTRIBUTE:
+ case
Hello Fujii-san,
Thank you for your comments.
The patch isn't applied to the master cleanly.
The compilation of the document failed with the following error message.
openjade:config.sgml:2188:12:E: end tag for element TERM which is not open
make[3]: *** [HTML.index] Error 1
xlog.c:930: warning:
Hi Michael, thanks for the review.
Michael Paquier wrote:
On Thu, Oct 16, 2014 at 4:01 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Oct 13, 2014 at 12:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this series.
Here is some input on
Jeff Janes wrote:
It is only a page read if you have to read the page. It would seem optimal
to have bgwriter adventitiously set hint bits and vm bits, because that is
the last point at which the page can be changed without risking that it be
written out twice. At that point, it has been
Andrew Dunstan wrote:
This bit:
+/*
+ * Determine how we want to render values of a given type in datum_to_jsonb.
+ *
+ * Given the datatype OID, return its JsonbTypeCategory, as well as the
type's
+ * output function OID. If the returned category is JSONBTYPE_CAST, we
+ * return the
Tom Lane wrote:
Not entirely sure what to do about this. It seems like for the purposes
of contrib/chkpass, it's a good thing that chkpass_in() won't reuse the
same salt. Weak as a 12-bit salt might be nowadays, it's still better
than no salt. Nonetheless, this behavior is breaking
On 2014-10-28 05:30:43 -0300, Alvaro Herrera wrote:
A couple of comments: this patch introduces a basic infrastructure able to
do the following set of operations:
- Obtention of parse tree using StashedCommand
- Reorganization of parse tree to become an ObjTree, with boolean, array
-
On 2014-10-28 14:34:22 +0900, Amit Langote wrote:
Hi,
From: Andres Freund [mailto:and...@2ndquadrant.com]
On 2014-10-27 06:29:33 -0300, Alvaro Herrera wrote:
Amit Langote wrote:
FWIW, I think Robert's criticism regarding not basing this on
inheritance
scheme was not responded
On Tue, Oct 28, 2014 at 4:54 PM, Syed, Rahila rahila.s...@nttdata.com wrote:
Hello Fujii-san,
Thank you for your comments.
The patch isn't applied to the master cleanly.
The compilation of the document failed with the following error message.
openjade:config.sgml:2188:12:E: end tag for element
Hi,
On 28/10/14 03:15, Michael Paquier wrote:
Updated patch with those comments addressed is attached.
Great, I have no further comments so I consider this patch ready for
committer (and will mark it so momentarily).
Just as a note - there is the issue you raised yourself about the less
On Tue, Oct 28, 2014 at 8:08 PM, Petr Jelinek p...@2ndquadrant.com wrote:
Hi,
On 28/10/14 03:15, Michael Paquier wrote:
Updated patch with those comments addressed is attached.
Great, I have no further comments so I consider this patch ready for
committer (and will mark it so
On 10/28/2014 02:56 AM, David G Johnston wrote:
Tom Lane-2 wrote
So maybe we shouldn't cling to the WAL-logging approach too much. Maybe
Heikki's idea from to abandon the full checkpoint and instead assume
that once the transaction commits, all the files were fsynced OK. Of
couse, this will do
On Tue, Oct 28, 2014 at 1:12 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10/27/2014 02:12 PM, Fujii Masao wrote:
On Fri, Oct 24, 2014 at 10:05 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
At least for master, we
On Tue, Oct 28, 2014 at 6:06 AM, Andres Freund and...@2ndquadrant.com wrote:
In my opinion we can reuse (some of) the existing logic for INHERITS to
implement proper partitioning, but that should be an implementation
detail.
Sure, that would be a sensible way to do it. I mostly care about not
On 2014-10-28 08:19:36 -0400, Robert Haas wrote:
On Tue, Oct 28, 2014 at 6:06 AM, Andres Freund and...@2ndquadrant.com wrote:
In my opinion we can reuse (some of) the existing logic for INHERITS to
implement proper partitioning, but that should be an implementation
detail.
Sure, that
On 13 October 2014 10:05, Petr Jelinek p...@2ndquadrant.com wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.
I've reviewed this and it looks good to me. Clean, follows existing
code
On 16 October 2014 10:18, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Please find attached to this email a patch to implement a new Event
Trigger, fired on the the table_rewrite event. As attached, it's meant
as a discussion enabler and only
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
+RoleId:CURRENT_USER{ $$ =
current_user;}
+ | USER { $$ = current_user;}
+ | CURRENT_ROLE { $$ =
On Sat, Oct 25, 2014 at 12:38 PM, Andreas Karlsson andr...@proxel.se
wrote:
Hi,
There was recently talk about if we should start using 128-bit integers
(where available) to speed up the aggregate functions over integers which
uses numeric for their internal state. So I hacked together a
On Mon, Oct 27, 2014 at 5:59 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
Attached is a patch with minor updates/corrections.
Given that no fewer than four people - all committers - have expressed
doubts about the design of this patch, I wonder why you're bothering
to post
On Sat, Oct 25, 2014 at 9:38 AM, Andreas Karlsson andr...@proxel.se wrote:
Hi,
There was recently talk about if we should start using 128-bit integers
(where available) to speed up the aggregate functions over integers which
uses numeric for their internal state. So I hacked together a patch
* Robert Haas (robertmh...@gmail.com) wrote:
There is absolutely NOT consensus on
this design or anything close to it.
There is no doubt that consensus on the desirability and design needs
to be reached before we can even consider committing it. I suspect
Adam posted it simply because he had
On 2014-10-28 11:05:11 -0200, Arthur Silva wrote:
On Sat, Oct 25, 2014 at 12:38 PM, Andreas Karlsson andr...@proxel.se
As far as I'm aware int128 types are supported on every major compiler when
compiling for 64bit platforms. Right?
Depends on what you call major. IIRC some not that old msvc
On 2014-10-28 09:24:18 -0400, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
There is absolutely NOT consensus on
this design or anything close to it.
There is no doubt that consensus on the desirability and design needs
to be reached before we can even consider
On 10/28/2014 02:05 PM, Arthur Silva wrote:
As far as I'm aware int128 types are supported on every major compiler
when compiling for 64bit platforms. Right?
Both gcc and clang support __int128_t, but I do not know about other
compilers like icc and MSVC.
Andreas
--
Sent via
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-10-28 09:24:18 -0400, Stephen Frost wrote:
There is no doubt that consensus on the desirability and design needs
to be reached before we can even consider committing it. I suspect
Adam posted it simply because he had identified issues
All,
* Stephen Frost (sfr...@snowman.net) wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
As I started looking at this, there are multiple other places where
these types of error messages occur (opclasscmds.c, user.c,
postinit.c, miscinit.c are just a few), not just around the
On 10/27/2014 06:12 PM, Heikki Linnakangas wrote:
On 10/27/2014 02:12 PM, Fujii Masao wrote:
On Fri, Oct 24, 2014 at 10:05 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
At least for master, we should consider changing the way the
On 2014-10-28 09:43:35 -0400, Stephen Frost wrote:
All,
* Stephen Frost (sfr...@snowman.net) wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
As I started looking at this, there are multiple other places where
these types of error messages occur (opclasscmds.c, user.c,
On 10/27/2014 05:57 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
This bit:
+/*
+ * Determine how we want to render values of a given type in datum_to_jsonb.
+ *
+ * Given the datatype OID, return its JsonbTypeCategory, as well as the type's
+ * output function OID. If the returned
On 10/28/2014 03:24 PM, Andres Freund wrote:
On 2014-10-28 11:05:11 -0200, Arthur Silva wrote:
On Sat, Oct 25, 2014 at 12:38 PM, Andreas Karlsson andr...@proxel.se
As far as I'm aware int128 types are supported on every major compiler when
compiling for 64bit platforms. Right?
Depends on what
* Andres Freund (and...@2ndquadrant.com) wrote:
For one I'm less than convinced that the new messages are an
improvement. They seem to be more verbose without a corresponding
improvement in clarity.
The goal with the changes is to improve consistency of messaging. These
messages are not at
On 2014-10-28 15:54:30 +0200, Heikki Linnakangas wrote:
On 10/28/2014 03:24 PM, Andres Freund wrote:
On 2014-10-28 11:05:11 -0200, Arthur Silva wrote:
On Sat, Oct 25, 2014 at 12:38 PM, Andreas Karlsson andr...@proxel.se
As far as I'm aware int128 types are supported on every major compiler
Heikki Linnakangas hlinnakan...@vmware.com writes:
It wouldn't be too hard to just do:
struct {
int64 high_bits;
uint64 low_bits;
} pg_int128;
and some macros for the + - etc. operators. It might be less work than
trying to deal with the portability issues of a native C
On 2014-10-24 11:25:23 -0400, Robert Haas wrote:
On Fri, Oct 24, 2014 at 10:10 AM, Andres Freund and...@2ndquadrant.com
wrote:
What I was thinking was that you'd append the messages to the layer one
level deeper than the parent. Then we'd missed the invalidations when
rolling back the
On 15 October 2014 13:08, Alexander Korotkov aekorot...@gmail.com wrote:
Postgres was initially designed to support access methods extendability.
This extendability lives to present day. However, this is mostly internal
in-core extendability. One can quite easily add new access method into
On 10/28/2014 04:06 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
It wouldn't be too hard to just do:
struct {
int64 high_bits;
uint64 low_bits;
} pg_int128;
and some macros for the + - etc. operators. It might be less work than
trying to deal with the
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost sfr...@snowman.net wrote:
That said, it sounds like the primary concern has been if we want this
feature at all and there hasn't been much discussion of the design
itself. Comments about the technical design would be great. I
appreciate your
On 10/28/2014 03:40 PM, Heikki Linnakangas wrote:
The patch doesn't do division with the 128-bit integers. It only does
addition and multiplication. Those are pretty straightforward to implement.
The patch uses division when converting from __int128_t to Numeric.
- Andreas
--
Sent via
Stephen Frost sfr...@snowman.net wrote:
You can still double-quote reserved words and use them in general. What
we're talking about here are cases where a word can't be used even if
it's double-quoted, and we try really hard to keep those cases at an
absolute minimum. We should also really
On Tue, Oct 28, 2014 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Or put it another way, it will be easier to write new index AMs
because we'll be able to skip the WAL part until we know we want it.
I like the feature you are proposing, but I don't think that we should
block Alexander
On Tue, Oct 28, 2014 at 2:40 AM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
Taking a step back, I'm still not sure I understand the need for this
feature or the use case. It seems to have started as a potential fix to an
inconsistency between ALTER USER and ALTER ROLE
On 10/28/2014 04:47 PM, Andreas Karlsson wrote:
On 10/28/2014 03:40 PM, Heikki Linnakangas wrote:
The patch doesn't do division with the 128-bit integers. It only does
addition and multiplication. Those are pretty straightforward to implement.
The patch uses division when converting from
On 10/28/2014 04:01 PM, Heikki Linnakangas wrote:
Moving on to other issues, isn't 128 bits too small to store the squares
of the processed numbers? That could overflow..
Yeah, which is why stddev_*(int8) and var_*(int8) still have to use
Numeric in the aggregate state. For the int2 and int4
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost sfr...@snowman.net wrote:
That said, it sounds like the primary concern has been if we want this
feature at all and there hasn't been much discussion of the design
itself. Comments about the
Do we release the buffers for compressed data when fpw is changed from
compress to on?
The current code does not do this.
Don't we need to do that?
Yes this needs to be done in order to avoid memory leak when compression is
turned off at runtime while the backend session is running.
You don't
Robert,
Given that no fewer than four people - all committers - have expressed
doubts about the design of this patch, I wonder why you're bothering
to post a new version.
I understand and my intent was in no way to disregard those concerns. The
only reason that I have posted a new version
On 28 October 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 28, 2014 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Or put it another way, it will be easier to write new index AMs
because we'll be able to skip the WAL part until we know we want it.
I like the feature
Hi,
On 2014-10-15 16:08:38 +0400, Alexander Korotkov wrote:
Postgres was initially designed to support access methods extendability.
This extendability lives to present day. However, this is mostly internal
in-core extendability. One can quite easily add new access method into
PostgreSQL
* Kevin Grittner (kgri...@ymail.com) wrote:
Stephen Frost sfr...@snowman.net wrote:
You can still double-quote reserved words and use them in general. What
we're talking about here are cases where a word can't be used even if
it's double-quoted, and we try really hard to keep those cases
On Tue, Oct 28, 2014 at 7:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 28 October 2014 14:53, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 28, 2014 at 10:22 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Or put it another way, it will be easier to write new index AMs
because
* Andres Freund (and...@2ndquadrant.com) wrote:
The other thing I'm not sure about is that I'm unconvinced that we
really want external AMs...
I was wondering about this also and curious as to if there's been any
prior on-list discussion about this proposal that I've simply missed..?
Would be
On 28 October 2014 16:19, Stephen Frost sfr...@snowman.net wrote:
Would be happy to go back and review earlier discussions, of course, but
I don't recall there being any.
It depends how far back you go.
I think I've had at least 2 tries at writing something, but not in last 5 years.
--
On 28 October 2014 14:22, Simon Riggs si...@2ndquadrant.com wrote:
Or put it another way, it will be easier to write new index AMs
because we'll be able to skip the WAL part until we know we want it.
To be clear: I am suggesting you do *less* work, not more.
By allowing AMs to avoid writing
Stephen Frost sfr...@snowman.net writes:
* Andres Freund (and...@2ndquadrant.com) wrote:
The other thing I'm not sure about is that I'm unconvinced that we
really want external AMs...
I was wondering about this also and curious as to if there's been any
prior on-list discussion about this
On 2014-10-28 13:06:52 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Andres Freund (and...@2ndquadrant.com) wrote:
The other thing I'm not sure about is that I'm unconvinced that we
really want external AMs...
I was wondering about this also and curious as to if
Hi,
On 2014-10-25 18:09:36 -0400, Steve Singer wrote:
I sometimes get the error snapshot too large from my logical replication
walsender process when in response to a CREATE_REPLICATION_SLOT.
Yes. That's possible if 'too much' was going on until a consistent point
was reached. I think we can
On 2014-10-25 18:18:07 -0400, Steve Singer wrote:
My logical decoding plugin is occasionally getting this error
could not resolve cmin/cmax of catalog tuple
I get this when my output plugin is trying to read one of the user defined
catalog tables (user_catalog_table=true)
Hm. That should
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-28 13:06:52 -0400, Tom Lane wrote:
But having said that, it's quite unclear to me that we need the
CREATE/DROP ACCESS METHOD infrastructure proposed here. The traditional
theory about that is that if you're competent to develop an AM at
Hi Guys,
I propose a lag (and/or lead) window function that propagates the last
non-null value to the current row.
Here's an example of what I mean by that:
CREATE TABLE lag_test (id serial primary key, natural_key integer,
somebody text);
INSERT INTO lag_test(natural_key, somebody)
VALUES
On 28 October 2014 17:06, Tom Lane t...@sss.pgh.pa.us wrote:
My own thought is that allowing external AMs is simply a natural
consequence of PG's general approach to extensibility, and it would
be surprising if we were to decide we didn't want to allow that.
If it wasn't clear from my two
On 2014-10-28 17:45:36 +, Simon Riggs wrote:
I'd like to avoid all of the pain by making persistent AMs that are
recoverable after a crash, rather than during crash recovery.
Besides the actual difficulities of supporting this, imo not being
available on HS and directly after a failover
On Tue, Oct 28, 2014 at 11:33 AM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
Given that no fewer than four people - all committers - have expressed
doubts about the design of this patch, I wonder why you're bothering
to post a new version.
I understand and my intent was
On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost sfr...@snowman.net wrote:
There are more capabilities that I've been considering longer-term but
wasn't sure if they should be independent or just lumped into the
simpler read/write category:
read (eg: importing log files, or importing from an
Simon Riggs si...@2ndquadrant.com writes:
On 28 October 2014 17:06, Tom Lane t...@sss.pgh.pa.us wrote:
My own thought is that allowing external AMs is simply a natural
consequence of PG's general approach to extensibility, and it would
be surprising if we were to decide we didn't want to allow
On 2014-10-28 13:37:33 -0400, Tom Lane wrote:
I'm not at all sold on the idea that we need to support dropping AMs.
I think it'd be fine to consider that installing an AM into a given
database is a one-way operation. Then you just need to insert some
pg_depend entries that pin the AM's
On 10/28/14, 9:22 AM, Simon Riggs wrote:
2. Some additional code in Autovacuum to rebuild corrupt indexes at
startup, using AV worker processes to perform a REINDEX CONCURRENTLY.
I don't think loading more functionality into autovac is the right way to do
that.
--
Jim Nasby, Data Architect,
On Tue, Oct 28, 2014 at 8:04 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 28 October 2014 14:22, Simon Riggs si...@2ndquadrant.com wrote:
Or put it another way, it will be easier to write new index AMs
because we'll be able to skip the WAL part until we know we want it.
To be clear: I
* Alexander Korotkov (aekorot...@gmail.com) wrote:
Having access methods as extensions can significantly improves situations
here. Imagine, GIN was an extension. One day we decide to change its binary
format. Then we can issue new extension, GIN2 for instance. User can
upgrade from GIN to GIN2
On Tue, Oct 28, 2014 at 01:51:21PM -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 28 October 2014 17:06, Tom Lane t...@sss.pgh.pa.us wrote:
My own thought is that allowing external AMs is simply a natural
consequence of PG's general approach to extensibility, and it
Robert Haas robertmh...@gmail.com wrote:
I think it would help, on all accounts, to explain why in the world
we're spending time on this in the first place. I have a sneaking
suspicion this is 1 of N things we need to do to meet some US
government security standard, and if something like
On 10/14/2014 03:59 PM, MauMau wrote:
BTW, in LWLockWaitForVar(), the first line of the following code fragment is
not necessary, because lwWaitLink is set to head immediately. I think it
would be good to eliminate as much unnecessary code as possible from the
spinlock section.
Marti Raudsepp wrote:
On Fri, Oct 24, 2014 at 11:29 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
- 0001-ALTER-ROLE-CURRENT_USER_v2.patch - the patch.
+RoleId:CURRENT_USER{ $$ =
current_user;}
+ | USER
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
2014-10-28 13:20 GMT+01:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
+1
Pavel
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2014 05:20 AM, Alvaro Herrera wrote:
Alex Goncharov wrote:
This is a misfeature for the benefit of edit-lazy users only.
+1
+1
Joe
- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Kevin,
Thanks.
* Kevin Grittner (kgri...@ymail.com) wrote:
Stephen my correct me on this, but I seem to remember him saying
that this was part of a general effort to avoid needing to use a
superuser login for routine tasks that don't fit into the area of
what a sysadmin would do. That seems
There are actually TWO tables involved: the table upon which
the trigger will actually fire, and some other table which is
mentioned in passing in the trigger definition. It's possible that
the locking requirements for the secondary table are weaker since I
don't think the presence of the
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost sfr...@snowman.net wrote:
There are more capabilities that I've been considering longer-term but
wasn't sure if they should be independent or just lumped into the
simpler read/write
Stephen Frost sfr...@snowman.net wrote:
the original ask was to be able to view logs as a DBA who isn't a
superuser, and without having to have those views delayed or
complex cron jobs running to set up access to them.
I had kinda forgotten it, but I had to set up a cron log rsync at
On 28 October 2014 17:47, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-28 17:45:36 +, Simon Riggs wrote:
I'd like to avoid all of the pain by making persistent AMs that are
recoverable after a crash, rather than during crash recovery.
Besides the actual difficulities of
On 28 October 2014 17:58, Alexander Korotkov aekorot...@gmail.com wrote:
Also, I'm not sure that many users have enough of courage to use unlogged
AMs. Absence of durability is only half of trouble, another half is lack of
streaming replication. I think if we have unlogged GIN then external
On 28 October 2014 17:50, Jim Nasby jim.na...@bluetreble.com wrote:
On 10/28/14, 9:22 AM, Simon Riggs wrote:
2. Some additional code in Autovacuum to rebuild corrupt indexes at
startup, using AV worker processes to perform a REINDEX CONCURRENTLY.
I don't think loading more functionality
There is already a patch for that (ignore/respect nulls in lead/lag):
https://commitfest.postgresql.org/action/patch_view?id=1096
--
Vladimir
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 16 October 2014 16:22, Robert Haas robertmh...@gmail.com wrote:
Might I gently enquire what the something usable we are going to see
in this release? I'm not up on current plans.
I don't know how far I'm going to get for this release yet. I think
pg_background is a pretty good milestone,
hi, guys,
I am looking for a couple pointers here about fdw, and how to change the
option values during CREATE table time.
I am using postgres-xc-1.2.1 right now. For example, it contains file_fdw,
whose create-table-stmt looks like:
CREATE FOREIGN TABLE t1()
SERVER file_server
On Tue, Oct 28, 2014 at 12:40 PM, Kirk Roybal k...@webfinish.com wrote:
Hi Guys,
I propose a lag (and/or lead) window function that propagates the last
non-null value to the current row.
Here's an example of what I mean by that:
CREATE TABLE lag_test (id serial primary key, natural_key
On Oct 24, 2014, at 6:36 AM, Alex Goncharov alex.goncharov@gmail.com
wrote:
Another dimension of the trouble is breaking the operation of the
tools that parse SQL statements for various purposes, e.g. for
dependency analysis.
That’s a valid point.
This is a misfeature for the benefit
On 10/28/2014 05:26 PM, Demai Ni wrote:
hi, guys,
I am looking for a couple pointers here about fdw, and how to change
the option values during CREATE table time.
I am using postgres-xc-1.2.1 right now. For example, it contains
file_fdw, whose create-table-stmt looks like:
CREATE FOREIGN
hi, Andrew,
thanks for the quick response.
M understanding is that Alter Foreign Table can change the option values by
user. What I need is to change the value programmatic inside foreign data
wrapper code, and hope someone already done so I can learn from the
existing design.
I thought this
On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost sfr...@snowman.net wrote:
To articular my own concerns perhaps a bit better, there are two major
things I don't like about the whole DIRALIAS proposal. Number one,
you're creating this SQL object whose name is not actually used for
anything other
On 10/28/14, 4:25 PM, David E. Wheeler wrote:
This is a misfeature for the benefit of edit-lazy users only.
This one, however, is more a judgment of people and their practices rather than
the feature itself. Color me unimpressed.
+1.
Having users sweat of comma placement in this day and age
On 10/28/14, 3:48 PM, Simon Riggs wrote:
Given your description of pg_background it looks an awful lot like
infrastructure to make Autonomous Transactions work, but it doesn't
even do that. I guess it could do in a very small additional patch, so
maybe it is useful for something.
What do you
On Tue, Oct 28, 2014 at 4:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 16 October 2014 16:22, Robert Haas robertmh...@gmail.com wrote:
Might I gently enquire what the something usable we are going to see
in this release? I'm not up on current plans.
I don't know how far I'm going to get
On 2014-10-28 20:17:57 +, Simon Riggs wrote:
On 28 October 2014 17:47, Andres Freund and...@2ndquadrant.com wrote:
On 2014-10-28 17:45:36 +, Simon Riggs wrote:
I'd like to avoid all of the pain by making persistent AMs that are
recoverable after a crash, rather than during crash
On Tue, Oct 28, 2014 at 7:22 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 10/28/14, 3:48 PM, Simon Riggs wrote:
Given your description of pg_background it looks an awful lot like
infrastructure to make Autonomous Transactions work, but it doesn't
even do that. I guess it could do in a very
On Tue, Oct 28, 2014 at 7:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 28, 2014 at 7:22 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 10/28/14, 3:48 PM, Simon Riggs wrote:
Given your description of pg_background it looks an awful lot like
infrastructure to make Autonomous
Jim Nasby jim.na...@bluetreble.com writes:
On 10/28/14, 4:25 PM, David E. Wheeler wrote:
This one, however, is more a judgment of people and their practices rather
than the feature itself. Color me unimpressed.
+1.
Having users sweat of comma placement in this day and age is pretty stupid.
On 7/17/14 3:31 PM, Tom Lane wrote:
My Salesforce colleagues have been complaining that the TAP tests added
in 9.4 don't work terribly well for them. I've been poking at this,
and I believe this is a reasonably complete list of the problems:
Quick followup:
1. make [install]check-world
1 - 100 of 115 matches
Mail list logo
