On lör, 2012-06-23 at 23:08 +0100, Dean Rasheed wrote:
I spotted a couple of other issues during testing:
* You're still allowing INCLUDING DEFAULTS and INCLUDING STORAGE, even
though these options are not supported on foreign tables.
* If I do INCLUDING ALL, I get an error because of the
On 24 June 2012 04:01, Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Dean Rasheed's message of sáb jun 23 18:08:31 -0400 2012:
I spotted a couple of other issues during testing:
David, when you generate a new version of the patch, please also make
sure to use
On 23 March 2012 18:38, David Fetter da...@fetter.org wrote:
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM,
Excerpts from Dean Rasheed's message of sáb jun 23 18:08:31 -0400 2012:
I spotted a couple of other issues during testing:
David, when you generate a new version of the patch, please also make
sure to use RELKIND_RELATION and RELKIND_FOREIGN instead of 'r' and 'f'.
* You're still allowing
The patch uses literals such as 'r' to identify the relkind values.
This should be using RELKIND_RELATION et al instead -- see
src/include/catalog/pg_class.h.
Other than that, it seems simple enough ...
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
On 23 March 2012 19:07, David Fetter da...@fetter.org wrote:
On Fri, Mar 23, 2012 at 11:38:56AM -0700, David Fetter wrote:
How about this one?
Oops, forgot to put the latest docs in.
I think the docs need some additional supporting content. The LIKE
clause and its source_table parameter
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead
On Fri, Mar 23, 2012 at 11:38:56AM -0700, David Fetter wrote:
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22
(2012/03/15 0:29), Tom Lane wrote:
The posted patch for file_fdw takes the
approach of silently filtering out rows for which they're not true,
which is not obviously the right thing either --- quite aside from
whether that's a sane semantics, it's not going to scale to foreign key
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead of inventing new grammar productions and a new
node type for
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead
On Thu, Mar 15, 2012 at 10:23 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Looks much better to me, but the use of strcmp() doesn't look good.
ISTM that stmtType is mostly used for error messages. I think you
should add some kind of identifier (such as the original parser Node)
into
On ons, 2012-03-14 at 17:38 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
If a constraint is NOT ENFORCED, then the query planner presumably
won't rely on it for planning purposes
Why do you presume that?
What
On Thu, Mar 15, 2012 at 11:23:43AM -0300, Alvaro Herrera wrote:
Excerpts from David Fetter's message of jue mar 15 02:28:28 -0300 2012:
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead
On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
Folks,
This is for 9.3, of course.
I noticed that CREATE FOREIGN TABLE (LIKE some_table) doesn't work. I
believe it should, as it would:
- Remove a POLA violation
- Make data loading into an extant table even easier,
On Wed, Mar 14, 2012 at 8:28 AM, David Fetter da...@fetter.org wrote:
On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
Folks,
This is for 9.3, of course.
I noticed that CREATE FOREIGN TABLE (LIKE some_table) doesn't work. I
believe it should, as it would:
- Remove a POLA
On Wed, Mar 14, 2012 at 08:53:17AM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 8:28 AM, David Fetter da...@fetter.org wrote:
On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
Folks,
This is for 9.3, of course.
I noticed that CREATE FOREIGN TABLE (LIKE some_table)
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 14, 2012 at 8:28 AM, David Fetter da...@fetter.org wrote:
Here's a WIP patch (lots of cut/paste, no docs, no tests), but it does
work. Still to do in addition: decide whether ALTER FOREIGN TABLE
should also handle LIKE.
I think that
On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 14, 2012 at 8:28 AM, David Fetter da...@fetter.org wrote:
Here's a WIP patch (lots of cut/paste, no docs, no tests), but it does
work. �Still to do in addition: decide whether
David Fetter da...@fetter.org writes:
I didn't do INHERITS because most FDWs won't ever have that concept,
i.e. aren't PostgreSQL.
What's that have to do with it? Inheritance would be a local
association of tables, having nothing to do with what the remote end is.
IOW, if c inherits from p,
David Fetter da...@fetter.org writes:
On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
Hm. That opinion seems to me to connect to the recently-posted
patch to make contrib/file_fdw enforce NOT NULL constraints. Should
we instead have the position that constraints declared for
On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
Hm. That opinion seems to me to connect to the recently-posted
patch to make contrib/file_fdw enforce NOT NULL constraints.
Should we
David Fetter da...@fetter.org writes:
On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
The posted patch for file_fdw takes the approach of silently
filtering out rows for which they're not true, which is not
obviously the right thing either --- quite aside from whether that's
a sane
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead of inventing new grammar productions and a new
node type for this, you should just reuse the existing productions for
LIKE clauses and then reject invalid options during parse analysis.
OK. Should I
On 14/03/2012 16:47, David Fetter wrote:
On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
Hm. That opinion seems to me to connect to the recently-posted
patch to make contrib/file_fdw
On Wed, Mar 14, 2012 at 12:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
The posted patch for file_fdw takes the approach of silently
filtering out rows for which they're not true, which is not
On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
That opinion seems to me to connect to the recently-posted patch to
make contrib/file_fdw enforce NOT NULL constraints. Should we instead
have the position that constraints declared for foreign tables are
statements that we can take on faith,
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
That opinion seems to me to connect to the recently-posted patch to
make contrib/file_fdw enforce NOT NULL constraints. Should we instead
have the position that constraints declared for foreign tables
On 03/14/2012 04:44 PM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
That opinion seems to me to connect to the recently-posted patch to
make contrib/file_fdw enforce NOT NULL constraints. Should we instead
have the position
On ons, 2012-03-14 at 16:44 -0400, Tom Lane wrote:
On reflection I don't see anything much wrong with the if you lied
about the constraint it's your fault that things broke position.
It seems quite comparable to the fact that we take the user's
assertions on faith as to the number and data
On Wed, Mar 14, 2012 at 5:14 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-03-14 at 16:44 -0400, Tom Lane wrote:
On reflection I don't see anything much wrong with the if you lied
about the constraint it's your fault that things broke position.
It seems quite comparable to the fact
On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
If a constraint is NOT ENFORCED, then the query planner presumably
won't rely on it for planning purposes
Why do you presume that?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
If a constraint is NOT ENFORCED, then the query planner presumably
won't rely on it for planning purposes
Why do you presume that?
What does SQL:2011 say exactly about the semantics of NOT
On Wed, Mar 14, 2012 at 5:21 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
If a constraint is NOT ENFORCED, then the query planner presumably
won't rely on it for planning purposes
Why do you presume that?
Well, as Tom alludes to, I'm
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter da...@fetter.org wrote:
I think that instead of inventing new grammar productions and a new
node type for this, you should just reuse the existing productions for
LIKE clauses and
35 matches
Mail list logo
