* Bruce Momjian (br...@momjian.us) wrote:
> Is this something for the next commit-fest?
I already moved it there..
Thanks,
Stephen
signature.asc
Description: Digital signature
Is this something for the next commit-fest?
---
Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Robert Haas writes:
> > > It seems there's at least one more thing to worry a
On Thu, Feb 17, 2011 at 10:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 17, 2011 at 4:53 PM, Tom Lane wrote:
>>> In short, add a bit of overhead at SetUserId time in order to make this
>>> cheap (and accurate) in elog.c.
>
>> As Stephen says, I think this is utterly impractical; t
Robert Haas writes:
> On Thu, Feb 17, 2011 at 4:53 PM, Tom Lane wrote:
>> In short, add a bit of overhead at SetUserId time in order to make this
>> cheap (and accurate) in elog.c.
> As Stephen says, I think this is utterly impractical; those routines
> can't ever throw any kind of error.
Why w
On Thu, Feb 17, 2011 at 4:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> It seems there's at least one more thing to worry about here, which is
>> the overhead of this computation when CSV logging is in use. If no
>> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
>> will ca
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > It seems there's at least one more thing to worry about here, which is
> > the overhead of this computation when CSV logging is in use. If no
> > SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> > will call show
Robert Haas writes:
> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use. If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none". We'll then st
Robert,
> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use. If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none". We'll then strcmp()
> tha
On Thu, Feb 17, 2011 at 11:45 AM, Stephen Frost wrote:
> Robert, if you say this has to be punted to 9.2 again, I'm giving up. ;)
Frankly, this patch has already consumed more than its fair share of
my attention. Having said that, I've just spent some more time on it.
I tightened up both the co
* Robert Haas (robertmh...@gmail.com) wrote:
> Ugg, wait a minute. This not only adds %U; it also changes the
> behavior of %u, which I don't think we've agreed on. Also, emitting
> 'none' when not SET ROLE has been done is pretty ugly. I'm back to
> thinking we need to push this out to 9.2 and
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, that just doesn't seem useful to me in the real world. If I were
> using this, I would expect it to emit a real user name that matches the
> currently applied permissions checking. All the time.
I wouldn't have ever thought to use %U w/o %u, to be h
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yeah, I thought what was supposed to be emitted was the value of
>> current_user, not SQL's weird definition of what SET ROLE means.
> current_user uses GetUserNameFromId() and goes through the cache lookups
> to get there. I was
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Ugg, wait a minute. This not only adds %U; it also changes the
> > behavior of %u, which I don't think we've agreed on. Also, emitting
> > 'none' when not SET ROLE has been done is pretty ugly. I'm back to
> > thinking we need to
* Robert Haas (robertmh...@gmail.com) wrote:
> Ugg, wait a minute. This not only adds %U; it also changes the
> behavior of %u, which I don't think we've agreed on. Also, emitting
> 'none' when not SET ROLE has been done is pretty ugly. I'm back to
> thinking we need to push this out to 9.2 and
Robert Haas writes:
> Ugg, wait a minute. This not only adds %U; it also changes the
> behavior of %u, which I don't think we've agreed on. Also, emitting
> 'none' when not SET ROLE has been done is pretty ugly. I'm back to
> thinking we need to push this out to 9.2 and take more time to think
On Wed, Feb 16, 2011 at 9:52 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Ah, so it does. Sounds like you win. Have we a patch implementing
>> the sounds-like-its-agreed change, then?
>
> Patch attached, rebased to current master.
Ugg, wait a minute. This not only
* Robert Haas (robertmh...@gmail.com) wrote:
> Ah, so it does. Sounds like you win. Have we a patch implementing
> the sounds-like-its-agreed change, then?
Patch attached, rebased to current master. Full git log:
Thanks,
Stephen
commit 47eebe20deb5da56ea6eb413ee801108
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Feb 16, 2011 at 8:58 PM, Stephen Frost wrote:
> > This list appears to miss out on
> > 8217cfbd991856d25d73b0f7afcf43d99f90b653 ..?
>
> Ah, so it does. Sounds like you win. Have we a patch implementing
> the sounds-like-its-agreed change, t
On Wed, Feb 16, 2011 at 8:58 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> CSV log files were introduced in 8.3.0 by commit
>> fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on
>> commits making adjustments, but they all appear to be 8.3-vintage:
>
* Robert Haas (robertmh...@gmail.com) wrote:
> CSV log files were introduced in 8.3.0 by commit
> fd801f4faa8e0f00bc314b16549e3d8e8aa1b653. There are several follow-on
> commits making adjustments, but they all appear to be 8.3-vintage:
>
> 230e8962f3a47cae4729ad7c017410d28caf1370
> 3bf66d6f1c3a8
On 02/16/2011 08:38 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I can't remember at the moment: have we changed the CSV format in any
releases since it was first created? And if so, did anyone complain?
It was changed between 8.4 and 9.0 (application_name was added). I'v
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I can't remember at the moment: have we changed the CSV format in any
> releases since it was first created? And if so, did anyone complain?
It was changed between 8.4 and 9.0 (application_name was added). I've
looked around a bit in the archives w/ googl
On Wed, Feb 16, 2011 at 7:42 PM, Tom Lane wrote:
> Robert Haas writes:
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
> I believe the suggestion that Robert and I were talking about above was
> to just unilatterally change the CSV log file output format to include
> curre
Robert Haas writes:
>>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
I believe the suggestion that Robert and I were talking about above was
to just unilatterally change the CSV log file output format to include
current_role. No header lines, no variable output format, et
On Wed, Feb 16, 2011 at 5:55 PM, Andrew Dunstan wrote:
> On 02/16/2011 04:24 PM, Robert Haas wrote:
>>
>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
>>>
>>> * Andrew Dunstan (and...@dunslane.net) wrote:
On 02/15/2011 11:13 AM, Stephen Frost wrote:
>
> Think I suggeste
On 02/16/2011 04:24 PM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
On 02/15/2011 11:13 AM, Stephen Frost wrote:
Think I suggested that at one point. I'm all for doing that on a major
version change like this one, b
On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost wrote:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> On 02/15/2011 11:13 AM, Stephen Frost wrote:
>> >Think I suggested that at one point. I'm all for doing that on a major
>> >version change like this one, but I think we already had some concer
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 02/15/2011 11:13 AM, Stephen Frost wrote:
> >Think I suggested that at one point. I'm all for doing that on a major
> >version change like this one, but I think we already had some concerns
> >about that on this thread (Andrew maybe?).
>
> I coul
On 02/15/2011 11:13 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it could be judged adequate for this
On Tue, Feb 15, 2011 at 11:13 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Well, I guess the other option is to just add it to the format, full
>> stop. But as someone pointed out previously, that's not a terribly
>> scalable solution, but perhaps it could be judged
* Robert Haas (robertmh...@gmail.com) wrote:
> Well, I guess the other option is to just add it to the format, full
> stop. But as someone pointed out previously, that's not a terribly
> scalable solution, but perhaps it could be judged adequate for this
> particular case.
Think I suggested that
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Given that this has been like this right along, I don't see why it's
> all that urgent to force a half-baked solution into 9.1. I'm also
> concerned that if we do do that, you'll lose motivation to work on
> cleaning it up for 9.2 ;-)
The addition to
On Tue, Feb 15, 2011 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> Something along these lines would be OK with me (I haven't yet
>> validated every detail), but there were previous objections to adding
>> any new fields to log_line_prefix until we had a flexible CSV format.
>> I think th
Robert Haas writes:
> Something along these lines would be OK with me (I haven't yet
> validated every detail), but there were previous objections to adding
> any new fields to log_line_prefix until we had a flexible CSV format.
> I think that's raising the bar a bit too high, personally, but I do
On Tue, Feb 15, 2011 at 10:37 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> The payoff
>>> (getting %U) seems quite out of proportion to the potential downsides
>>> of making a change of this type at this late date.
>
>> I'd be happy to go back to
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> The payoff
>> (getting %U) seems quite out of proportion to the potential downsides
>> of making a change of this type at this late date.
> I'd be happy to go back to the original patch/idea of just the simple
> addition of %
On Tue, Feb 15, 2011 at 10:26 AM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> I'd be happy to go back to the original patch/idea of just the simple
>> addition of %U as an option for log_line_prefix.
>
> Updated patch attached which just adds %U support to log_line_prefix
* Stephen Frost (sfr...@snowman.net) wrote:
> I'd be happy to go back to the original patch/idea of just the simple
> addition of %U as an option for log_line_prefix.
Updated patch attached which just adds %U support to log_line_prefix.
Will work on adding CSV support for this in 9.2, along with
* Stephen Frost (sfr...@snowman.net) wrote:
> Ugh, sorry about that, I should have realized that needed to be done.
> Updated patch attached.
Errr, for real this time.
Thanks,
Stephen
commit 25e94dcb390f56502bc46e683b438c20d2dc74e0
Author: Stephen Frost
Date: Tue Feb
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost wrote:
> > > * In assign_csvlog_fields(), we need to cleanup memory and memory context
> > > before return on error.
> > Fixed this and a couple of similar issues.
>
> Not yet fixed. Switched mem
* Robert Haas (robertmh...@gmail.com) wrote:
> The payoff
> (getting %U) seems quite out of proportion to the potential downsides
> of making a change of this type at this late date.
I'd be happy to go back to the original patch/idea of just the simple
addition of %U as an option for log_line_pref
On Fri, Feb 11, 2011 at 6:20 PM, Kevin Grittner
wrote:
> I wrote:
>>> Patch attached.
>
> This time with src/backend/utils/misc/postgresql.conf.sample fixed.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Tue, Feb 15, 2011 at 12:46 AM, Itagaki Takahiro
wrote:
> On Mon, Feb 14, 2011 at 23:30, Stephen Frost wrote:
>> > * In assign_csvlog_fields(), we need to cleanup memory and memory context
>> > before return on error.
>> Fixed this and a couple of similar issues.
>
> Not yet fixed. Switched mem
On Mon, Feb 14, 2011 at 23:30, Stephen Frost wrote:
> > * In assign_csvlog_fields(), we need to cleanup memory and memory context
> > before return on error.
> Fixed this and a couple of similar issues.
Not yet fixed. Switched memory context is not restored on error.
> Updated patch attached, gi
Itagaki,
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> We need to design csvlog_header more carefully. csvlog_header won't work
> if log_filename is low-resolution, ex. log-per-day.
This isn't any different a problem to the issue of someone changing the
csvlog_fields GUC but not checki
On Mon, Feb 14, 2011 at 11:51, Stephen Frost wrote:
>> It would be awfully nice if we could inject something into the csvlog
>> output format that would let client programs know which fields are
>> present. This would be especially useful for people writing tools
>> that are intended to work on A
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
> See the discussion back around the the 8.1 release (IIRC) when we
> added the HEADER option.
I recall seeing it and not agreeing with it then. :)
> >If I wanted something to throw away the first record of a file before
> >loading it, I'd us
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost wrote:
> > Updated patch attached, full git log below.
Thanks again for the review. Updated patch attached.
> The documentation for csvlog_fields should probably use
> around the default val
On 02/13/2011 08:26 AM, Stephen Frost wrote:
This would be called a 'header' in most typical CSV scenarios.
Unfortunately, last I checked (maybe it's changed?), COPY w/ HEADER just
throws the header away instead of doing anything useful with it. If it
actually used the header to build the colu
* Robert Haas (robertmh...@gmail.com) wrote:
> The documentation for csvlog_fields should probably use
> around the default value.
>
> The sentence that begins "For details on what these fields are" should
> hyperlink the referenced sections of the documentation.
>
> The function prototype you a
On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost wrote:
> Updated patch attached, full git log below.
The documentation for csvlog_fields should probably use
around the default value.
The sentence that begins "For details on what these fields are" should
hyperlink the referenced sections of the
I wrote:
> Patch attached.
This time with src/backend/utils/misc/postgresql.conf.sample fixed.
-Kevin
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 5188,5202 dynamic_library_path =
'C:\tools\postgresql;H:\my_project\lib;$libdir'
Stephen Frost wrote:
> Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd be happy with "max_pred_locks_per_transaction" which gets the
>> worst case down without being too obviously at variance with
>> "max_locks_per_transaction".
>
> Sounds good to me. The header length for show all would drop to
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> $ which collateindex.pl
> /usr/bin/collateindex.pl
> $ rpm -qf /usr/bin/collateindex.pl
> docbook-style-dsssl-1.79-11.fc13.noarch
Ah-hah, thanks for that! Apparently on Debian it's docbook-dsssl that
contains it, and yes, it gets installed into /usr/bin (n
Excerpts from Tom Lane's message of vie feb 11 13:49:33 -0300 2011:
> Stephen Frost writes:
> > * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> >> You might need "yum install openjade stylesheets" or similar packages
> >> and re-"configure".
>
> > I've got openjade, etc, installed, but I
Stephen Frost writes:
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> You might need "yum install openjade stylesheets" or similar packages
>> and re-"configure".
> I've got openjade, etc, installed, but I'm on Debian and it doesn't
> appear to include that collateindex.pl anywhere..
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > If we're going to abbreviate transaction, I'd vote for txn over tran,
> > but I think Stephen's point that this is already a lost cause may have
> > some validity. Not sure what other people think.
I agree w/ reducing that particul
Robert Haas writes:
> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
> wrote:
>> Should we abbreviate something there? max_pred_locks_per_tran,
>> maybe?
> If we're going to abbreviate transaction, I'd vote for txn over tran,
> but I think Stephen's point that this is already a lost cause may
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote:
> > Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl',
> > apparently..).
>
> You might need "yum install openjade stylesheets" or similar packages
> and re-"configure".
I'
* Robert Haas (robertmh...@gmail.com) wrote:
> Yeah. The root cause of this problem is that the way psql handles
> tabular output with a few very wide rows stinks.
True, but it would be kinda nice to support multi-line configuration
variables. I still vote for that being "not required to get thi
On Fri, Feb 11, 2011 at 10:52 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
>> > Should we abbreviate something there? max_pred_locks_per_tran,
>> > maybe?
>>
>> If we're going to abbreviate transaction, I'd vote for tx
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
> > Should we abbreviate something there? max_pred_locks_per_tran,
> > maybe?
>
> If we're going to abbreviate transaction, I'd vote for txn over tran,
> but I think Stephen's point that this is alread
On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
wrote:
>>Stephen Frost wrote:
>
>> That, plus the length of max_predicate_locks_per_transaction,
>> would make 'show all;' go beyond 80 characters even if we took out
>> the description
>
> Should we abbreviate something there? max_pred_locks_per_
>Stephen Frost wrote:
> That, plus the length of max_predicate_locks_per_transaction,
> would make 'show all;' go beyond 80 characters even if we took out
> the description
Should we abbreviate something there? max_pred_locks_per_tran,
maybe?
-Kevin
--
Sent via pgsql-hackers mailing list
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think it's entirely stupid to worry about this completely
> screwing up the output of "SHOW ALL" on people using 80-character
> terminal windows. I haven't checked, but if it renders the output
> totally unreadable then I think we should try t
On Thu, Feb 10, 2011 at 6:27 AM, Noah Misch wrote:
> FWIW, a 330 byte boot_val doesn't seem like a big deal to me. If it were over
> _POSIX2_LINE_MAX (2048), that might be another matter.
I don't think it's entirely stupid to worry about this completely
screwing up the output of "SHOW ALL" on pe
On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote:
> >> I agree that it's logically good design, but we could not accept it
> >> as long as it breaks tools in the real world...
> > If it does, I think it's pretty clear that those
On Mon, Feb 7, 2011 at 04:10, Stephen Frost wrote:
> Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl',
> apparently..).
You might need "yum install openjade stylesheets" or similar packages
and re-"configure".
> Ok, I've cleaned up that part of the documentation to be a table in
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> Could you try to "make html" in the doc directory?
Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl',
apparently..).
> Your new decumentation after
> | These columns may be included in the CSV output:
> will be unaligned pla
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I agree that it's logically good design, but we could not accept it
> as long as it breaks tools in the real world...
If it does, I think it's pretty clear that those tools are themselves
broken..
> Will it break "SHOW ALL" and "SELECT * FR
On Sun, Feb 6, 2011 at 23:31, Stephen Frost wrote:
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> I think we need to improve postgresql.conf.sample a bit more, especially
>> the long line for #log_csv_fields = '...'. 330 characters in it!
>> #1. Leave the long line because it is nee
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I think we need to improve postgresql.conf.sample a bit more, especially
> the long line for #log_csv_fields = '...'. 330 characters in it!
> #1. Leave the long line because it is needed.
It's needed to match what the current default is..
> Updated patch attached.
I think we need to improve postgresql.conf.sample a bit more, especially
the long line for #log_csv_fields = '...'. 330 characters in it!
#1. Leave the long line because it is needed.
#2. Hide the variable from the default conf.
#3. Use short %x mnemonic both in log
Itagaki,
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> Discussions
> * How about "csvlog_fields" rather than "log_csv_fields"?
> Since we have variables with syslog_ prefix, csvlog_ prefix
> seems to be better.
Sure, not a big deal, to be honest, as long as we can actuall
On Wed, Jan 19, 2011 at 14:36, Stephen Frost wrote:
> Alright, here's the latest on this patch. I've added a log_csv_fields
> GUC along with the associated magic to make it work (at least for me).
> Also added 'role_name' and '%U' options. Requires postmaster restart to
> change, didn't include
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Point being, until we get Andrew's jagged-csv-import magic committed to
> > core, we won't be able to import a log file that a user has changed the
> > field list for mid-stream (following the add-a-new-column use-case we've
> > be
On 01/17/2011 11:44 AM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of sáb ene 15 00:34:40 -0300 2011:
Stephen Frost writes:
What about something other than
version_x_y? I could maybe see having a 'default' and an 'all'
instead.. Then have the default be what we have currently a
Excerpts from Tom Lane's message of sáb ene 15 00:34:40 -0300 2011:
> Stephen Frost writes:
> > What about something other than
> > version_x_y? I could maybe see having a 'default' and an 'all'
> > instead.. Then have the default be what we have currently and 'all' be
> > the full list I'm thi
On 01/15/2011 11:08 AM, Tom Lane wrote:
Robert Haas writes:
On Fri, Jan 14, 2011 at 9:24 PM, Andrew Dunstan wrote:
What's your suggestion, then?
If there's a practical way to add the requested escape, add it to the
text format and leave reengineering the CSV format for another day.
Yeah, I
Robert Haas writes:
> On Fri, Jan 14, 2011 at 9:24 PM, Andrew Dunstan wrote:
>> What's your suggestion, then?
> If there's a practical way to add the requested escape, add it to the
> text format and leave reengineering the CSV format for another day.
> Yeah, I know that's not the most beautiful
On Fri, Jan 14, 2011 at 9:24 PM, Andrew Dunstan wrote:
> On 01/14/2011 08:41 PM, Robert Haas wrote:
>> I think we're in the process of designing a manned mission to Mars to
>> solve the problem that our shoelaces are untied.
> What's your suggestion, then?
If there's a practical way to add the re
Stephen Frost writes:
> Okay, next user-interface question- thoughts on handling SIGHUP? My
> first reaction is that we should create a new log file on SIGHUP (if we
> don't already, havn't checked), or maybe just on SIGHUP if this variable
> changes.
> Point being, until we get Andrew's jagged-
Stephen Frost writes:
> I'd been puzzling over how to deal with this big list of fields in
> postgresql.conf and I do like the idea of some kind of short-cut being
> provided to ease the pain for users.
Yeah, I agree with the worry that a default value that's a mile long
is going to be a bit of a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, an array or list of integer codes was what I was thinking too.
Hm, yeah, a list of integer codes might be even better/simpler.
Okay, next user-interface question- thoughts on handling SIGHUP? My
first reaction is that we should create a new log file
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> everything that looks at this GUC value
> will know instantly what it is for each version.
> The last bit is kind of a killer for tools like pgfouine, no?
Ugh.. Could we just accept it as input but return the full list if
asked for it>
> In any case I tho
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In any case, if the GUC representation is a list of field names, I think
>> the POLA demands that the system honor the list order.
> Agreed. That puts us back into the question of how to make it
> efficient. My best thought at
Andrew Dunstan writes:
> The only thing I'd suggest extra is that we might allow "version_n_m" as
> shorthand for the default table layout from the relevant version.
Mmm ... seems like that just complicates matters. To make that useful,
you have to assume that there *is* a default table layout,
* Andrew Dunstan (and...@dunslane.net) wrote:
> The only thing I'd suggest extra is that we might allow
> "version_n_m" as shorthand for the default table layout from the
> relevant version.
I like that idea, makes the default a lot simpler to deal with too. :)
Thanks!
St
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In any case, if the GUC representation is a list of field names, I think
> the POLA demands that the system honor the list order.
Agreed. That puts us back into the question of how to make it
efficient. My best thought at the moment, which doesn't strik
On 01/14/2011 09:51 PM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A user-settable column list seems pretty on-target
for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to contr
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> A user-settable column list seems pretty on-target
>> for solving those problems to me.
> I'm looking into implementing this.
> An interesting initial question is- should the users be able to control
> the *order* of the columns?
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> A user-settable column list seems pretty on-target
> for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to control
the *order* of the columns? My gut feeling, if we're giving
Robert Haas writes:
> On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane wrote:
>> I was thinking of it as being strictly a field list.
> I think we're in the process of designing a manned mission to Mars to
> solve the problem that our shoelaces are untied.
How so? ISTM the problems at hand are (a) we
On 01/14/2011 08:41 PM, Robert Haas wrote:
I think we're in the process of designing a manned mission to Mars to
solve the problem that our shoelaces are untied.
What's your suggestion, then?
cheers
andre
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I was thinking of it as being strictly a field list. I don't know
>> whether it's really practical to borrow log_line_prefix's one-character
>> names for the fields (for one thing, there would need to be names for
>> all the existi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > If you have a format string, what do you want to do with the bits of the
> > format that aren't field references?
>
> I was thinking of it as being strictly a field list. I don't know
> whether it's really practical to borrow l
On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 01/14/2011 05:08 PM, Tom Lane wrote:
>>> It actually sounded like a pretty good idea to me.
>
>> If you have a format string, what do you want to do with the bits of the
>> format that aren't field references?
>
> I w
Andrew Dunstan writes:
> On 01/14/2011 05:08 PM, Tom Lane wrote:
>> It actually sounded like a pretty good idea to me.
> If you have a format string, what do you want to do with the bits of the
> format that aren't field references?
I was thinking of it as being strictly a field list. I don't
On 01/14/2011 05:08 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/14/2011 11:48 AM, Stephen Frost wrote:
My first thought would be to have a 'log_csv_format' GUC that's very
similar to 'log_line_prefix' (and uses the same variables if
possible..). We could then ship a default in postgres
Aidan Van Dyk writes:
> If there is going to be any change, how about using fixed columns (an
> possibly allowing them to be empty for stuff that's expensive to
> create/write), but adding a 1st column that contains a "version"
> identifyer. And to make it easy, maybe the PG major version as the
1 - 100 of 135 matches
Mail list logo
