On Thu, Sep 1, 2016 at 3:15 AM, Kyotaro HORIGUCHI
wrote:
> At Wed, 31 Aug 2016 07:26:22 -0400, Tom Lane wrote in
> <5934.1472642...@sss.pgh.pa.us>
>> Robert Haas writes:
>> > On Tue, Aug 30, 2016 at 6:38 PM, Tom Lane wrote:
>> >> Robert, could you fix the documentation for that field so it's
>
At Wed, 31 Aug 2016 07:26:22 -0400, Tom Lane wrote in
<5934.1472642...@sss.pgh.pa.us>
> Robert Haas writes:
> > On Tue, Aug 30, 2016 at 6:38 PM, Tom Lane wrote:
> >> Robert, could you fix the documentation for that field so it's
> >> intelligible?
>
> > Uh, maybe. The trick, as you've already
Robert Haas writes:
> On Tue, Aug 30, 2016 at 6:38 PM, Tom Lane wrote:
>> Robert, could you fix the documentation for that field so it's
>> intelligible?
> Uh, maybe. The trick, as you've already noted, is finding something
> better. Maybe this:
> -boolsingle_copy;/* path must
On Tue, Aug 30, 2016 at 6:38 PM, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
>> - boolsingle_copy;/* path must not be executed >1x */
>> + boolsingle_copy;/* path must not span on multiple
>> processes */
>
> I agree that the existing comment sucks, but th
Kyotaro HORIGUCHI writes:
> - boolsingle_copy;/* path must not be executed >1x */
> + boolsingle_copy;/* path must not span on multiple
> processes */
I agree that the existing comment sucks, but this isn't a lot better
(and it will probably not look nice
Hello.
The comment on GatherPath.single_copy is the following.
===
/*
* GatherPath runs several copies of a plan in parallel and collects the
* results. The parallel leader may also execute the plan, unless the
* single_copy flag is set.
*/
typedef struct GatherPath
{
Path
On Wed, Jun 8, 2016 at 7:06 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
>> wrote:
>> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
>> > wrote:
>> >> I have added an open item for 9.6 regarding this patch, that would be
>> >> good to c
Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete this work in this release for consistency with the
> >>
On Tue, Jun 7, 2016 at 7:35 AM, Alvaro Herrera wrote:
> In looking at the DROP ACCESS METHOD completion I noticed that the
> words_after_create gadget is a bit buggy: for things with more than one
> word in the thing name (such as MATERIALIZED VIEW, USER MAPPING FOR,
> EVENT TRIGGER among others)
Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete this work in this release for consistency with the
> >>
Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 9.6 open item. Álvaro,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> 9.6 open item, please let us know. Otherw
On Thu, Jun 02, 2016 at 04:00:33PM +0900, Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete this work in
On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
wrote:
> On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> wrote:
>> I have added an open item for 9.6 regarding this patch, that would be
>> good to complete this work in this release for consistency with the
>> other objects.
>
> Doh. I forgot to
On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
wrote:
> I have added an open item for 9.6 regarding this patch, that would be
> good to complete this work in this release for consistency with the
> other objects.
Doh. I forgot to update psql --help.
--
Michael
From 9901595fd000c3ac9e1c1ce8ee2f2
On Wed, Jun 1, 2016 at 8:25 PM, Teodor Sigaev wrote:
As far as I can see, COMMENT ON has no support for access methods.
Wouldn't we want to add it as it is created by a command? On top of
that, perhaps we could have a backslash command in psql to list the
supported access metho
As far as I can see, COMMENT ON has no support for access methods.
Wouldn't we want to add it as it is created by a command? On top of
that, perhaps we could have a backslash command in psql to list the
supported access methods, like \dam[S]? The system methods would be in
this case all the in-cor
On Wed, Jun 1, 2016 at 4:52 AM, Robert Haas wrote:
> On Fri, May 27, 2016 at 7:53 AM, Michael Paquier
> wrote:
>> As far as I can see, COMMENT ON has no support for access methods.
>> Wouldn't we want to add it as it is created by a command? On top of
>> that, perhaps we could have a backslash co
On Fri, May 27, 2016 at 7:53 AM, Michael Paquier
wrote:
> As far as I can see, COMMENT ON has no support for access methods.
> Wouldn't we want to add it as it is created by a command? On top of
> that, perhaps we could have a backslash command in psql to list the
> supported access methods, like
Michael Paquier writes:
> As far as I can see, COMMENT ON has no support for access methods.
> Wouldn't we want to add it as it is created by a command? On top of
> that, perhaps we could have a backslash command in psql to list the
> supported access methods, like \dam[S]? The system methods woul
Hi all,
As far as I can see, COMMENT ON has no support for access methods.
Wouldn't we want to add it as it is created by a command? On top of
that, perhaps we could have a backslash command in psql to list the
supported access methods, like \dam[S]? The system methods would be in
this case all th
On 11/21/13, 3:29 PM, Elvis Pranskevichus wrote:
> I may be totally missing something, but there seems to be no way
> to create a COMMENT on a domain constraint. There is
>
> COMMENT ON CONSTRAINT constraint_name ON table_name
>
> but no such thing for domain constraints, which seems like a
>
Hello,
I may be totally missing something, but there seems to be no way
to create a COMMENT on a domain constraint. There is
COMMENT ON CONSTRAINT constraint_name ON table_name
but no such thing for domain constraints, which seems like a
weird omission.
I couldn't find any relevant discuss
Robert Haas writes:
> On Tue, Jun 12, 2012 at 10:59 PM, Vlad Arkhipov wrote:
>> Does it make sense to have a comment on function's arguments?
> This would be somewhat tricky, because our COMMENT support assumes
> that the object upon which we're commenting has an ObjectAddress, and
> individual
On Tue, Jun 12, 2012 at 10:59 PM, Vlad Arkhipov wrote:
> Does it make sense to have a comment on function's arguments? Of course it
> is possible to include these comments in a function's comment, but may be
> better to have them in more formalized way like comments on columns of a
> table. IDEs m
Does it make sense to have a comment on function's arguments? Of course
it is possible to include these comments in a function's comment, but
may be better to have them in more formalized way like comments on
columns of a table. IDEs may use this information when providing hints
for a function
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This doesn't look good. If we throw a WARNING, why do we not insert
> anything into pg_description. Seems we should throw an error, or do the
> insert with a warning.
Throwing an error breaks existing pg_dump files. Doing the insertion is
simply wrong
Rod Taylor wrote:
-- Start of PGP signed section.
> On Mon, 2004-03-08 at 15:46, Bruce Momjian wrote:
> > This doesn't look good. If we throw a WARNING, why do we not insert
> > anything into pg_description. Seems we should throw an error, or do the
> > insert with a warning.
>
> It used to be a
Rod Taylor wrote:
On Mon, 2004-03-08 at 14:46, Andrew Dunstan wrote:
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the us
Rod Taylor <[EMAIL PROTECTED]> writes:
> Comments longer than ~7k would need a toast table. At the moment, toast
> tables don't work on a global basis.
Sure they do ... in fact, all the shared catalogs have one.
I think the idea of putting comments directly into pg_shadow and friends
is too icky
Bruce Momjian wrote:
This doesn't look good. If we throw a WARNING, why do we not insert
anything into pg_description. Seems we should throw an error, or do the
insert with a warning.
It essentially makes the behavior deprecated and allows dumps to be
restored properly (without the extra-databa
This doesn't look good. If we throw a WARNING, why do we not insert
anything into pg_description. Seems we should throw an error, or do the
insert with a warning.
---
Mike Mascari wrote:
> Andrew Dunstan wrote:
> > Bruce M
Andrew Dunstan wrote:
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the user/group comments in those tables instead of in
pg_descriptio
It's rumoured that Andrew Dunstan once said:
> Bruce Momjian wrote:
>
>>Another problem is that pg_description is per-database, while
>>pg_user/group are global for all databases.
>>
>>
>>
> databases are also per cluster, but we have comments on those.
>
> Could we keep the user/group comments in
Bruce Momjian wrote:
Another problem is that pg_description is per-database, while
pg_user/group are global for all databases.
databases are also per cluster, but we have comments on those.
Could we keep the user/group comments in those tables instead of in
pg_description?
cheers
andrew
--
Tom Lane wrote:
> "Clark C. Evans" <[EMAIL PROTECTED]> writes:
> > It would be wonderful to be able to create comments
> > on users and groups. In particular, I need a place
> > to store the user's name. Yes, I could make a user
> > table, but that seems overkill as all of the other
> > aspects o
"Clark C. Evans" <[EMAIL PROTECTED]> writes:
> It would be wonderful to be able to create comments
> on users and groups. In particular, I need a place
> to store the user's name. Yes, I could make a user
> table, but that seems overkill as all of the other
> aspects of a user are already in the
It would be wonderful to be able to create comments
on users and groups. In particular, I need a place
to store the user's name. Yes, I could make a user
table, but that seems overkill as all of the other
aspects of a user are already in the metadata.
Best,
Clark
--
Clark C. Evans
Hi list,
First of all, many thanks to everyone who contributed to 7.4 - I'm just
starting to rebuild parts of our CMS to make use of some of the new
features - very welcome indeed.
Whilst looking through the new information_schema objects in the DB, and
browsing the documentation for these objec
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> COMMENT ON AGGREGATE my_aggregate double precision IS 'Computes
> sample variance';
>
> works but looks strange syntax. Should we fix the program or docs?
>> I vote for fixing the program.
> If we fix this, we should also change DROP AGGREGATE, w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> COMMENT ON AGGREGATE my_aggregate double precision IS 'Computes
>> sample variance';
>>
>> works but looks strange syntax. Should we fix the program or docs?
> I vote for fixing the program.
If we fix this, we should also change DROP AGGREGATE, wh
Tatsuo Ishii writes:
> In comment.sgml:
>
> COMMENT ON AGGREGATE my_aggregate (double precision) IS 'Computes
> sample variance';
>
> this raises error. However,
>
> COMMENT ON AGGREGATE my_aggregate double precision IS 'Computes
> sample variance';
>
> works but looks strange syntax. Should we f
In comment.sgml:
COMMENT ON AGGREGATE my_aggregate (double precision) IS 'Computes
sample variance';
this raises error. However,
COMMENT ON AGGREGATE my_aggregate double precision IS 'Computes
sample variance';
works but looks strange syntax. Should we fix the program or docs?
--
Tatsuo Ishii
42 matches
Mail list logo
