On Mon, Jul 11, 2011 at 12:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of dom jul 10 21:21:19 -0400 2011:
On Jul 9, 2011, at 10:49 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
In short: in my opinion, attoptions and attfdwoptions need
Robert Haas robertmh...@gmail.com writes:
... I think we should understand
attoptions as things that modify the behavior of PostgreSQL, while
attfdw/genoptions are there solely for the foreign data wrapper to
use. An extra nullable field in pg_attribute isn't costing us
anything non-trivial,
On Mon, Jul 18, 2011 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... I think we should understand
attoptions as things that modify the behavior of PostgreSQL, while
attfdw/genoptions are there solely for the foreign data wrapper to
use. An extra
All,
Is the spec for this feature still under discussion? I don't seem to
see a consensus on this thread.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
(2011/07/15 4:17), Josh Berkus wrote:
All,
Is the spec for this feature still under discussion? I don't seem to
see a consensus on this thread.
Yeah, a remaining concern is whether generic (FDW) options should be
separated from existing attoptions or not.
Indeed, reloptions/attoptions
(2011/07/12 0:44), Peter Eisentraut wrote:
On lör, 2011-07-09 at 23:49 -0400, Alvaro Herrera wrote:
The new ALTER TABLE grammar seems a bit strange -- ADD, SET, DROP. Is
this defined by the SQL/MED standard? It seems at odds with our
handling of attoptions
Well, I believe the SQL/MED
On Jul 12, 2011, at 12:31 AM, Shigeru Hanada shigeru.han...@gmail.com wrote:
(2011/07/11 10:21), Robert Haas wrote:
On Jul 9, 2011, at 10:49 PM, Alvaro Herreraalvhe...@commandprompt.com
wrote:
In short: in my opinion, attoptions and attfdwoptions need to be one
thing and the same.
I feel
(2011/07/12 21:19), Robert Haas wrote:
On Jul 12, 2011, at 12:31 AM, Shigeru Hanadashigeru.han...@gmail.com wrote:
I'm afraid that I've misunderstood the discussion. Do you mean that
per-table options should be stored in reloptions, but per-column should
be separated from attoptions? (I
Excerpts from Shigeru Hanada's message of mar jul 12 03:11:54 -0400 2011:
(2011/07/12 0:44), Peter Eisentraut wrote:
On lör, 2011-07-09 at 23:49 -0400, Alvaro Herrera wrote:
The new ALTER TABLE grammar seems a bit strange -- ADD, SET, DROP. Is
this defined by the SQL/MED standard? It
On tis, 2011-07-12 at 09:56 -0400, Alvaro Herrera wrote:
Speaking of which -- what's the difference between ADD and SET for
SQL/MED options?
ADD add to the existing options, SET overwrites all options with what
you specify.
--
Sent via pgsql-hackers mailing list
(2011/07/12 22:56), Alvaro Herrera wrote:
Speaking of which -- what's the difference between ADD and SET for SQL/MED
options?
ADD can only add new option; it can't overwrite existing option's value.
To overwrite existing option's value, you need to use SET instead.
Regards,
--
Shigeru Hanada
On lör, 2011-07-09 at 23:49 -0400, Alvaro Herrera wrote:
The new ALTER TABLE grammar seems a bit strange -- ADD, SET, DROP. Is
this defined by the SQL/MED standard? It seems at odds with our
handling of attoptions
Well, I believe the SQL/MED options were actually implemented first and
the
(2011/07/11 10:21), Robert Haas wrote:
On Jul 9, 2011, at 10:49 PM, Alvaro Herreraalvhe...@commandprompt.com
wrote:
In short: in my opinion, attoptions and attfdwoptions need to be one
thing and the same.
I feel the opposite. In particular, what happens when a future release
of
On Jul 9, 2011, at 10:49 PM, Alvaro Herrera alvhe...@commandprompt.com wrote:
In short: in my opinion, attoptions and attfdwoptions need to be one
thing and the same.
I feel the opposite. In particular, what happens when a future release of
PostgreSQL adds an attoption that happens to have the
Excerpts from Robert Haas's message of dom jul 10 21:21:19 -0400 2011:
On Jul 9, 2011, at 10:49 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
In short: in my opinion, attoptions and attfdwoptions need to be one
thing and the same.
I feel the opposite. In particular, what happens
Shigeru Hanada escribió:
(2011/06/26 18:34), Kohei KaiGai wrote:
I checked your patch.
Thanks for the review! Please find attached a revised patch.
Err, \dec seems to have a line in describe.h but nowhere else; are you
going to introduce that command?
The new ALTER TABLE grammar seems a
(2011/07/04 10:17), Shigeru Hanada wrote:
(2011/07/03 18:50), Kohei KaiGai wrote:
I checked the per-column generic option patch.
Right now, I have nothing to comment on anymore.
So, it should be reviewed by committers.
Thanks for the review!.
I would like to propose adding force_not_null
Hanada-san,
I checked the per-column generic option patch.
Right now, I have nothing to comment on anymore.
So, it should be reviewed by committers.
Thanks,
2011年6月27日16:47 Shigeru Hanada shigeru.han...@gmail.com:
(2011/06/26 18:34), Kohei KaiGai wrote:
I checked your patch.
Thanks for the
(2011/07/03 18:50), Kohei KaiGai wrote:
I checked the per-column generic option patch.
Right now, I have nothing to comment on anymore.
So, it should be reviewed by committers.
Thanks for the review!.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list
2011/6/27 Shigeru Hanada shigeru.han...@gmail.com:
* It might be an option to extend attreloptions, instead of the new
attfdwoptions.
Although I didn't track the discussion when pg_foreign_table catalog
that provides
relation level fdw-options, was it impossible or unreasonable to extend
On Fri, Jun 17, 2011 at 05:59:31AM -0700, David Fetter wrote:
On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
Here's an example of a non-trivial mapping.
Database type:
MySQL
Foreign data type:
datetime
PostgreSQL data type:
timestamptz
I checked your patch.
The backend portion seems to me OK, but I have several questions/comments.
* This patch should be rebased.
It conflicts with the latest bin/psql/describe.c and
include/catalog/catversion.h.
IIRC, we should not touch catversion.h in submission stage. (It might
be a task of
(2011/06/17 8:44), David Fetter wrote:
Sorry not to respond sooner.
First, the per-column generic options are a great thing for us to
have. :)
Thanks for the comments. :-)
I have an idea I've been using for the next release of DBI-Link that
has varying levels of data type mapping. In
On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
(2011/06/17 8:44), David Fetter wrote:
Sorry not to respond sooner.
First, the per-column generic options are a great thing for us to
have. :)
Thanks for the comments. :-)
I have an idea I've been using for the next
On Tue, Jun 14, 2011 at 05:56:05PM +0900, Shigeru Hanada wrote:
Hi,
I would like to propose support for per-column generic option, which
is defined in the SQL/MED standard. In 9.0 release, support for
foreign tables and per-table generic option have been added, but
support for per-column
Hi,
I would like to propose support for per-column generic option, which is
defined in the SQL/MED standard. In 9.0 release, support for foreign
tables and per-table generic option have been added, but support for
per-column generic option hasn't.
Please examine the description below and
I haven't looked at the patch yet, but here are a few comments on the
design, which overall looks good.
2011/6/14 Shigeru Hanada shigeru.han...@gmail.com:
1) psql should support describing per-column generic options, so \dec
command was added. If the form \dec+ is used, generic options are
27 matches
Mail list logo
