On Mon, Jul 18, 2011 at 3:26 PM, Tom Lane wrote:
> Robert Haas 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 i
Robert Haas 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, and the syntacti
On Mon, Jul 11, 2011 at 12:11 AM, Alvaro Herrera
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
>> wrote:
>> > In short: in my opinion, attoptions and attfdwoptions need to be one
>> > thing and the same.
>>
>> I fee
(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 m
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:
http://www.postgres
(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 Hanad
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 (pgsql-hackers@postgresql.o
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?
(2011/07/12 21:19), Robert Haas wrote:
> On Jul 12, 2011, at 12:31 AM, Shigeru Hanada 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 think I've misread...
On Jul 12, 2011, at 12:31 AM, Shigeru Hanada wrote:
> (2011/07/11 10:21), Robert Haas wrote:
>> On Jul 9, 2011, at 10:49 PM, Alvaro Herrera
>> wrote:
>>> In short: in my opinion, attoptions and attfdwoptions need to be one
>>> thing and the same.
>>
>> I feel the opposite. In particular, what h
(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 options
(2011/07/11 10:21), Robert Haas wrote:
> On Jul 9, 2011, at 10:49 PM, Alvaro Herrera
> 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 attoptio
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
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
> 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 releas
On Jul 9, 2011, at 10:49 PM, Alvaro Herrera 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 same name as somebody's
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
(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_no
(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 (pgsql-hackers@postgr
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 :
> (2011/06/26 18:34), Kohei KaiGai wrote:
>> I checked your patch.
>
> Thanks for the review! Please find
Sorry for the long delay...
(2011/06/17 21:59), David Fetter wrote:
> 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. :)
>>
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:
>
2011/6/27 Shigeru Hanada :
>> * 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
>> existing
>> des
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
co
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 f
(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. I
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-col
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 :
> 1) psql should support describing per-column generic options, so \dec
> command was added. If the form \dec+ is used, generic options are also
> displayed. Output
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 attache
28 matches
Mail list logo
