On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 1:20 AM, Merlin Moncure wrote:
I'm piling on: it's not clear at all to me why you've special cased
this to lower_bound=1. First of all, there are other reasons to check
length than iteration.
Yes, I agree. A length
On 10 January 2014 08:12, David Rowley dgrowle...@gmail.com wrote:
On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Hi,
Reading over this, I realised that there is a problem with NaN
handling --- once the state becomes NaN, it can never recover. So the
results
On 19 December 2013 08:05, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/12/19 David Fetter da...@fetter.org
On Wed, Dec 18, 2013 at 09:27:54PM +0100, Marko Tiikkaja wrote:
Hi,
Attached is a patch to add support for array_length(anyarray), which
only works for one-dimensional
On 15 December 2013 01:57, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
I think even the FLOAT case deserves some consideration. What's the
worst-case drift?
Complete loss of all significant digits.
The case I was considering earlier of single-row windows could
On 9 January 2014 15:19, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as other quals are
preprocessed. But thinking about it further, those
On 24 December 2013 12:12, Craig Ringer cr...@2ndquadrant.com wrote:
On 12/24/2013 03:21 PM, Abbas Butt wrote:
Could you please explain a little bit more how would you solve the posed
problem using map_variable_attnos?
It actually turns out to be even simpler, and easy to do in one pass,
On 13 December 2013 01:14, Tom Lane t...@sss.pgh.pa.us wrote:
The only thing I've come across that arguably doesn't work is SELECT
DISTINCT:
regression=# select distinct from pg_database;
--
(8 rows)
The reason this says 8 rows is that the produced plan is just a seqscan
of pg_database
On 13 December 2013 15:07, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
I can't think of any practical uses for this kind of query, so I don't
think it's worth worrying too much about its results until/unless
someone comes up with a real use-case.
However
On 5 December 2013 10:06, Pavel Stehule pavel.steh...@gmail.com wrote:
I think #1175 is close to being ready for commit. Pavel, will you
produce an updated patch based on our last discussion? I'll set this
patch to waiting on author.
I expected so your version was a final. I have no problem
On 3 December 2013 23:37, Tom Lane t...@sss.pgh.pa.us wrote:
Thinking some more about bug #8648, it occurred to me that ruleutils.c
isn't exactly prepared for the case either:
regression=# create table nocols();
CREATE TABLE
regression=# create view vv1 as select exists (select * from
On 2 December 2013 04:55, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
it looks well, thank you
Regards
Pavel
I've been thinking about this some more, and there's another case that
concerns me slightly. We're now making some of the DROP...IF EXISTS
commands tolerate non-existent
On 5 December 2013 01:33, Peter Eisentraut pete...@gmx.net wrote:
Can someone in this thread clarify the commit fest situation? I see two
entries that appear to be the same:
https://commitfest.postgresql.org/action/patch_view?id=1174
On 2 December 2013 19:37, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Dean Rasheed escribió:
+/*
+ * If a schema was explicitly specified, test if it exists. If it does not,
+ * report the schema as missing rather than the child object.
+ */
+static bool
+schema_does_not_exist_skipping
On 1 December 2013 07:32, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/11/30 Peter Eisentraut pete...@gmx.net
trailing whitespace
fixed,
Hi,
I've been looking at this and I think it's mostly in good shape, but I
spotted a few minor issues:
* There's a typo in the notice text in a
On 26 November 2013 19:54, Peter Eisentraut pete...@gmx.net wrote:
On 11/24/13, 2:28 PM, Pavel Stehule wrote:
Note: DROP TRIGGER ON tablename is PostgreSQL feature - no other
databases (without PostgreSQL forks) uses this syntax - so we don't need
thinking what is in (or what will be) in ANSI
On 20 November 2013 22:46, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom 1. Reinsert HEAD's prohibition against directly combining WITH
Tom ORDINALITY with a coldeflist (with a better error message and a
Tom HINT suggesting that you can get
On 21 November 2013 13:15, Craig Ringer cr...@2ndquadrant.com wrote:
Hi all
I have updatable security barrier views working for INSERT and DELETE,
so this might be a good chance to see whether the described approach is
acceptable in reality, not just in theory.
I've been surprised by how
On 12 November 2013 16:00, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
here is patch with fault tolerant drop trigger and drop rule support
drop trigger [if exists] trgname on [if exists] tablename;
drop rule [if exists] trgname on [if exists] tablename;
Regards
Pavel
Hi,
I
On 6 November 2013 19:12, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/11/6 Craig Ringer cr...@2ndquadrant.com:
On 11/05/2013 09:36 PM, Robert Haas wrote:
I haven't studied this patch in detail, but I see why there's some
unhappiness about that code: it's an RLS-specific kluge. Just
shooting
On 6 November 2013 09:23, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/06/2013 05:02 PM, Dean Rasheed wrote:
The basic idea is to have rewriteTargetView() collect up any quals
from SB views in a new list on the target RTE, instead of adding them
to the main query's predicates (it needs
On 24 October 2013 18:28, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-23 21:20:58 +0100, Dean Rasheed wrote:
On 23 October 2013 21:08, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
Hmm, my first thought is that rewriteTargetView
On 23 October 2013 02:18, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Using the same debugging hack^Wpatch (0001) as in the matview patch
(0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK
doesn't lock the underlying relations properly.
I've attached a sort-of-working
On 23 October 2013 21:08, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-23 20:51:27 +0100, Dean Rasheed wrote:
On 23 October 2013 02:18, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Using the same debugging hack^Wpatch (0001) as in the matview patch
(0002) an hour or so ago I
On 18 October 2013 15:43, Robert Haas robertmh...@gmail.com wrote:
Committed.
Excellent. Thank you!
And thank you Marko for your thorough review.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 18 October 2013 16:41, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 18, 2013 at 1:34 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Personally, I think this is too fancy anyway. I'd just complete all
views and foreign tables and be done with it. We don't inspect
permissions
On 17 October 2013 03:29, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-07-08 at 16:04 +, Dean Rasheed wrote:
There was concern that pg_relation_is_updatable() would end up opening
every relation in the database, hammering performance. I now realise
that these tab-complete queries
On 20 September 2013 11:29, Samrat Revagade revagade.sam...@gmail.com wrote:
Okay, are you adding this to the september commitfest?
OK, I've done that. I think that it's too late for 9.3.
+1 for idea.
I have tested patch and got surprising results with Cent-OS
Patch is working fine
On 14 May 2013 16:35, Peter Eisentraut pete...@gmx.net wrote:
Sometimes, the psql startup hangs when it cannot resolve or connect to a
host. Intuitively, I would like to press Ctrl+C and correct the
connection string or investigate. But that doesn't work because Ctrl+C
is already bound to
On 13 August 2013 00:01, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2013-08-07 at 21:19 -0400, Peter Eisentraut wrote:
To make the view updatable, provide an unconditional ON DELETE DO
INSTEAD rule or an INSTEAD OF DELETE trigger.
I think it's a bit strange to claim that adding a DELETE
On 30 July 2013 01:24, Stephen Frost sfr...@snowman.net wrote:
depesz,
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
create table some_data (id int4 primary key,
On 30 July 2013 11:09, hubert depesz lubaczewski dep...@depesz.com wrote:
On Tue, Jul 30, 2013 at 09:23:19AM +0100, Dean Rasheed wrote:
create table some_data (id int4 primary key, payload text);
create view first as select * from some_data where 0 = id % 2 with
local check option
On 23 July 2013 06:10, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
I must admit to finding all of this criticism of unread code a bit
bizarre.
If you yourself are still finding bugs in the code as of this afternoon,
onlookers could be forgiven for
On 18 July 2013 22:27, Stephen Frost sfr...@snowman.net wrote:
Dean,
* Stephen Frost (sfr...@snowman.net) wrote:
Thanks! This is really looking quite good, but it's a bit late and I'm
going on vacation tomorrow, so I didn't quite want to commit it yet. :)
Apologies on this taking a bit
On 19 July 2013 04:09, Greg Smith g...@2ndquadrant.com wrote:
On 7/18/13 11:03 PM, Stephen Frost wrote:
Wasn't there a wiki page about this
feature which might also help? Bigger question- is it correct for the
latest version of the patch?
https://wiki.postgresql.org/wiki/RLS has
On 11 July 2013 00:03, Bernd Helmle maili...@oopsware.de wrote:
--On 8. Juli 2013 16:04:31 + Dean Rasheed dean.a.rash...@gmail.com
wrote:
* pg_relation_is_updatable is only available in 9.3, whereas psql may
connect to older servers, so it needs to guard against that.
Oh of course, i
On 19 June 2013 18:12, Peter Eisentraut pete...@gmx.net wrote:
On 6/19/13 11:50 AM, Dean Rasheed wrote:
On 19 June 2013 15:22, Peter Eisentraut pete...@gmx.net wrote:
We still don't have any support for this in psql, do we?
No, but at least we now have an API that psql can use
On 8 July 2013 12:46, Bernd Helmle maili...@oopsware.de wrote:
Recently i got annoyed that psql doesn't tab complete to updatable foreign
tables.
Attached is a patch to address this. I'm using the new
pg_relation_is_updatable() function to accomplish this. The function could
also be used for
On 5 July 2013 18:23, David Fetter da...@fetter.org wrote:
Please find attached changes based on the above.
This looks good. The grammar changes are smaller and neater now on top
of the makeFuncCall() patch.
Overall I think this patch offers useful additional functionality, in
compliance with
On 5 July 2013 07:02, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
I try to check this patch
I have a problem with initdb after patching
error
initializing dependencies ... ok
creating system views ... FATAL: WITH CHECK OPTION is supported only
on auto-updatable views
STATEMENT:
On 4 July 2013 00:08, David Fetter da...@fetter.org wrote:
Patch re-jiggered for recent changes to master.
I re-validated this, and it all still looks good, so still ready for
committer IMO.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 1 July 2013 03:07, Nicholas White n.j.wh...@gmail.com wrote:
Alternatively, it might be trivial to make all aggregate functions work
with ignore nulls in a window context
This is a good idea, but I'd like to keep the scope of this patch limited
for the time being
Agreed.
- I'll look at
On 1 July 2013 03:07, Nicholas White n.j.wh...@gmail.com wrote:
I've attached another iteration of the patch that fixes the multiple-window
bug and adds ( uses) a function to create a Bitmapset using a custom
allocator. I don't think there's any outstanding problems with it now.
I just
On 1 July 2013 01:44, David Fetter da...@fetter.org wrote:
On Fri, Jun 28, 2013 at 09:22:52PM +0100, Dean Rasheed wrote:
On 21 June 2013 06:16, David Fetter da...@fetter.org wrote:
Please find attached a patch which allows subqueries in the FILTER
clause and adds regression testing for same
On 29 June 2013 17:30, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2013-06-24 at 18:01 +0100, Nicholas White wrote:
Good catch - I've attached a patch to address your point 1. It now
returns the below (i.e. correctly doesn't fill in the saved value if
the index is out of the window. However,
On 27 June 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom Lane said:
Agreed, separating out the function-call-with-trailing-declaration
syntaxes so they aren't considered in FROM and index_elem seems like
the best compromise.
If we do
On 21 June 2013 06:16, David Fetter da...@fetter.org wrote:
Please find attached a patch which allows subqueries in the FILTER
clause and adds regression testing for same.
This needs re-basing/merging following Robert's recent commit to make
OVER unreserved.
Regards,
Dean
--
Sent via
On 26 June 2013 22:48, Noah Misch n...@leadboat.com wrote:
On Wed, Jun 26, 2013 at 09:04:34PM +0100, Dean Rasheed wrote:
On 26 June 2013 19:32, Noah Misch n...@leadboat.com wrote:
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
md5_agg() is well-defined
On 26 June 2013 21:46, Peter Eisentraut pete...@gmx.net wrote:
On 6/26/13 4:04 PM, Dean Rasheed wrote:
A quick google search reveals several people asking for something like
this, and people recommending md5(string_agg(...)) or
md5(string_agg(md5(...))) based solutions, which are doomed
On 27 June 2013 17:47, Peter Eisentraut pete...@gmx.net wrote:
On 6/27/13 4:19 AM, Dean Rasheed wrote:
I'd say there are clearly people who want it, and the nature of some
of those answers suggests to me that we ought to have a better answer
in core.
It's not clear what these people wanted
On 26 June 2013 01:22, Josh Berkus j...@agliodbs.com wrote:
Folks,
(the below was already discussed on IRC)
Leaving names aside on this patch, I'm wondering about a piece of
functionality I have with the current unnest() and with the
unnest_ordinality()[1] extension: namely, the ability to
On 26 June 2013 01:01, Josh Berkus j...@agliodbs.com wrote:
I know it's heresy in these parts, but maybe we should consider
adopting a non-spec syntax for this feature? In particular, it's
really un-obvious why the FILTER clause shouldn't be inside rather
than outside the aggregate's parens,
On 26 June 2013 19:32, Noah Misch n...@leadboat.com wrote:
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
I've been playing around with the idea of an aggregate that computes
the sum of the md5 hashes of each of its inputs, which I've called
md5_total() for now, although I'm
On 24 June 2013 04:29, Josh Berkus j...@agliodbs.com wrote:
On 06/23/2013 08:00 PM, Andrew Gierth wrote:
OK, let's try to cover all the bases here in one go.
1. Stick with ?column? as a warning flag that you're not supposed to
be using this without aliasing it to something.
How do I
On 24 June 2013 03:50, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
I think it is OK if that gets a syntax error. If that's the worst
case I like this approach.
I think reducing the usefulness of
On 25 June 2013 18:17, Josh Berkus j...@agliodbs.com wrote:
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not
On 21 June 2013 08:31, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 June 2013 08:02, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 June 2013 06:54, David Fetter da...@fetter.org wrote:
For example SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file
The spec is pretty specific
On 21 June 2013 10:02, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 June 2013 06:16, David Fetter da...@fetter.org wrote:
On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
David Fetter escribió:
On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
In my
On 21 June 2013 21:04, David Fetter da...@fetter.org wrote:
On Fri, Jun 21, 2013 at 10:48:35AM -0700, David Fetter wrote:
On Mon, Jun 17, 2013 at 11:34:52AM +0100, Dean Rasheed wrote:
On 15 June 2013 10:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
There seem to be 2 separate directions
On 21 June 2013 06:54, David Fetter da...@fetter.org wrote:
For example SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file
The spec is pretty specific about the all or none nature of naming
in the AS clause...unless we can figure out a way of getting around it
somehow.
We already support
On 21 June 2013 08:02, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 June 2013 06:54, David Fetter da...@fetter.org wrote:
For example SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS file
The spec is pretty specific about the all or none nature of naming
in the AS clause...unless we can
On 21 June 2013 05:01, David Fetter da...@fetter.org wrote:
What tests do you think should be there that aren't?
I think I expected to see more tests related to some of the specific
code changes, such as
CREATE TABLE t AS SELECT * FROM generate_series(1,10) t(x);
-- Should fail (filter can't
On 21 June 2013 06:16, David Fetter da...@fetter.org wrote:
On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
David Fetter escribió:
On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
In my testing of sub-queries in the FILTER clause (an extension to the
spec
On 17 June 2013 06:36, David Fetter da...@fetter.org wrote:
Please find attached two versions of a patch which provides optional
FILTER clause for aggregates (T612, Advanced OLAP operations).
The first is intended to be applied on top of the previous patch, the
second without it.
On 19 June 2013 04:11, David Fetter da...@fetter.org wrote:
On Tue, Jun 18, 2013 at 11:36:08AM +0100, Dean Rasheed wrote:
On 17 June 2013 06:33, David Fetter da...@fetter.org wrote:
Next revision of the patch, now with more stability. Thanks, Andrew!
Rebased vs. git master.
Here's my
On 19 June 2013 15:22, Peter Eisentraut pete...@gmx.net wrote:
We still don't have any support for this in psql, do we?
No, but at least we now have an API that psql can use.
There are still a number of questions about the best way to display it in psql.
Should it be another column in \d+'s
On 19 June 2013 18:12, Peter Eisentraut pete...@gmx.net wrote:
On 6/19/13 11:50 AM, Dean Rasheed wrote:
On 19 June 2013 15:22, Peter Eisentraut pete...@gmx.net wrote:
We still don't have any support for this in psql, do we?
No, but at least we now have an API that psql can use
On 17 June 2013 06:33, David Fetter da...@fetter.org wrote:
Next revision of the patch, now with more stability. Thanks, Andrew!
Rebased vs. git master.
Here's my review of the WITH ORDINALITY patch.
Overall I think that the patch is in good shape, and I think that this
will be a very
On 15 June 2013 10:22, Dean Rasheed dean.a.rash...@gmail.com wrote:
There seem to be 2 separate directions that this could go, which
really meet different requirements:
1). Produce an unordered sum for SQL to compare 2 tables regardless of
the order in which they are scanned. A possible
On 13 June 2013 10:35, Dean Rasheed dean.a.rash...@gmail.com wrote:
Hi,
Attached is a patch implementing a new aggregate function md5_agg() to
compute the aggregate MD5 sum across a number of rows. This is
something I've wished for a number of times. I think the primary use
case is to do
On 14 June 2013 14:14, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Thu, Jun 13, 2013 at 12:35 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Attached is a patch implementing a new aggregate function md5_agg() to
compute the aggregate MD5 sum across a number
On 14 June 2013 15:19, Stephen Frost sfr...@snowman.net wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
I'd rather go the other way, processing the records without having
to process them otherwise at all. Turning things into text must slow
things down, surely.
That's certainly an
On 14 June 2013 16:09, Hannu Krosing ha...@2ndquadrant.com wrote:
What skytools/pgq/londiste uses for comparing tables on master
and slave is query like this
select sum(hashtext(t.*::text)) from yourtable t;
This is non-modulo sum and does not use md5 but relies on
whatever the hashtext()
On 13 June 2013 01:11, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
The more I read the spec, the less sense it seems to make, and each
time I read it, I seem to reach a different conclusion.
On my latest reading, I've almost convinced myself that updatable
On 9 June 2013 11:14, Dean Rasheed dean.a.rash...@gmail.com wrote:
Here's a rebased version of the patch implementing WITH CHECK OPTION
for auto-updatable views.
It now includes documentation, and a clearer description of the
patch's limitations --- WITH CHECK OPTION is only supported
Hi,
Attached is a patch implementing a new aggregate function md5_agg() to
compute the aggregate MD5 sum across a number of rows. This is
something I've wished for a number of times. I think the primary use
case is to do a quick check that 2 tables, possibly on different
servers, contain the same
On 12 June 2013 04:50, David E. Wheeler da...@justatheory.com wrote:
On Jun 11, 2013, at 3:09 PM, Brendan Jurd dire...@gmail.com wrote:
There have been attempts to add a cardinality function in the past, as
it is required by the SQL spec, but these attempts have stalled when
trying to decide
On 12 June 2013 18:35, Tom Lane t...@sss.pgh.pa.us wrote:
looking at this patch some more ...
Dean Rasheed dean.a.rash...@gmail.com writes:
One place where I think we have diverged from the spec, however, is in
information_schema.columns.updatable. This should be returning 'YES
On 12 June 2013 23:01, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
[ pg_relation_is_updatable.patch ]
I've committed this with some modifications as mentioned. There is
still room to debate exactly what
information_schema.columns.is_updatable means
On 11 June 2013 01:03, Michael Paquier michael.paqu...@gmail.com wrote:
Sorry for my late reply.
On Sun, Jun 9, 2013 at 6:45 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
I called it updatable rather than writable or read-only because it
might perhaps be extended in the future
On 11 June 2013 22:53, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
Here's a more complete patch along those lines. It defines the
following pair of functions to test for updatability from SQL:
FUNCTION pg_catalog.pg_relation_is_updatable(reloid oid
On 6 June 2013 08:09, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 5 June 2013 08:59, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm still not happy with pg_view_is_updatable() et al. and the
information_schema views. I accept that the information_schema views
have to be the way
On 5 June 2013 08:59, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm still not happy with pg_view_is_updatable() et al. and the
information_schema views. I accept that the information_schema views
have to be the way they are because that's what's defined in the
standard, but as it stands
On 4 June 2013 23:35, Michael Paquier michael.paqu...@gmail.com wrote:
On Wed, Jun 5, 2013 at 12:59 AM, Peter Eisentraut pete...@gmx.net wrote:
I was looking for a way in which the average psql user could learn
whether a view is updatable. I was expecting something in \d, \d+, \dv,
\dv+,
On 31 May 2013 08:34, Brendan Jurd dire...@gmail.com wrote:
On 31 May 2013 02:52, Dean Rasheed dean.a.rash...@gmail.com wrote:
Testing 9.3beta, it seems that array_remove() may return an empty 1-d
array whose upper bound is lower than its lower bound. I know that we
discussed allowing
Testing 9.3beta, it seems that array_remove() may return an empty 1-d
array whose upper bound is lower than its lower bound. I know that we
discussed allowing this kind of array, but I don't think that
discussion reached any conclusion, other than to agree that the
current empty 0-d array
On 16 May 2013 22:16, Tom Lane t...@sss.pgh.pa.us wrote:
Specifically, for foreign tables
information_schema.tables.is_insertable_into and
information_schema.columns.is_updatable always say 'NO' even if the
foreign table is writable. Fixing that would require new C functions
along the same
Hi,
I've just started 9.3 beta testing and I noticed that a simple view
defined on top of a writable foreign table is not automatically
updatable.
Given that these are both new-to-9.3 features, I think it would be a
shame if they don't work together. It's basically a 1-line patch to
make such
On 16 May 2013 22:16, Tom Lane t...@sss.pgh.pa.us wrote:
This is assuming that an FDW that defines, say, ExecForeignDelete
is thereby promising that *all* tables it supports are deletable. That
is not required by the current FDW API spec.
Ah OK, I didn't appreciate that distinction.
If we
here:
http://momjian.us/pgsql_docs/release-9-3.html
I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome. I still need to add lots of
SGML markup.
E.1.3.4.4. VIEWs:
* Make simple views auto-updatable (Dean Rasheed)
INSTEAD
On 3 April 2013 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
I think though that the upthread argument that we'd have multiple
interpretations of the same thing is bogus. To me, the core idea that's
being suggested here is that '{}' should mean a zero-length 1-D array,
not a zero-D array as
On 28 March 2013 03:01, Tom Lane t...@sss.pgh.pa.us wrote:
[snip]
ranges *are not arrays*.
OK, fair enough. I guess it's the mathematician in me seeing patterns
in things that behave similarly, but which are admittedly different.
Is the patch also going to allow empty arrays in higher
On 26 March 2013 20:44, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, you could easily change array_ndims() to error out if ARR_NDIM()
is negative or more than MAXDIM and return NULL only if it's exactly
0. That wouldn't break backward compatibility
On 27 March 2013 17:14, Brendan Jurd dire...@gmail.com wrote:
On 28 March 2013 00:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
The patch is also allowing '{{},{},{}}' which is described up-thread
as a 2-D empty array. That's pretty misleading, since it has length 3
(in the first dimension
On 28 March 2013 00:04, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
On 28 March 2013 09:39, Dean Rasheed dean.a.rash...@gmail.com wrote:
Maybe. But even in 1-D, it's still jumping from having one empty array
to infinitely many starting at different indexes, e.g
On 5 March 2013 13:46, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/5 Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp:
Hello,
I think that the only other behavioural glitch I spotted was that it
fails to catch one overflow case, which should generate an out of
ranger error:
On 2 March 2013 15:06, Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to
this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had a quick look at other DBs to see if there were any other
precedents out there. Oracle was
On 3 March 2013 13:12, Kevin Grittner kgri...@ymail.com wrote:
Dean Rasheed dean.a.rash...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
[ ... ] led to this thought:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
[Sorry to join this discussion so late]
FWIW I had
On 28 February 2013 11:25, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Umm. sorry,
If you have no problem with this, I'll send this to committer.
I just found that this patch already has a revewer. I've seen
only Status field in patch list..
Should I leave this to you, Dean?
On 11 February 2013 14:29, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
updated patch
* merged Dean's doc
* allow NULL as width
Hi,
I have not had time to look at this properly, but it doesn't look as
though you have fixed the other problem I mentioned up-thread, with %s
for NULL
On 10 February 2013 12:37, Pavel Stehule pavel.steh...@gmail.com
Here is my first draft. I've also attached the generated HTML page,
because it's not so easy to read an SGML patch.
nice
I have only one point - I am think, so format function should be in
table 9-6 - some small text with
301 - 400 of 605 matches
Mail list logo
