Re: [BUGS] pg_restore ignores -C when using a restore list -L
On 15/05/10 03:26, Tom Lane wrote: > Russell Smith writes: > >>> By the operation of other items (-C --data-only) passed with -l, it only >>> produces to contents that would be restored with the other switches >>> provided. If that's expect behavior, then the documentation of the >>> switch is incorrect and should read something more like >>> >>> -l >>> --list List the items in the archive that would be restored >>> taking into account any other switches provided. The output of this >>> operation can be used with the -L option to further restrict and >>> reorder the items that are restored. >>> > Yeah, -l is limited by other filtering switches, and this definitely > ought to be stated more clearly in the documentation. (The content > of the produced file implies it, since it says *Selected* TOC Entries, > but that's hardly clear enough.) > > >> Further to these comments, both scenarios should make -l or -L >> incompatibe with -C --data-only -I -n --schema-only -T -t -x as all >> these alter the contents of what is restored. You should either use the >> list to control the items restored or the switches. Using both just >> created confusion. >> > I believe that allowing the filter switches to act on -l is a useful > behavior, and anyway it's been like that for many years and nobody's > complained before. So I'm not excited about taking out the > functionality. > > However, I think -C is a special case because it's quite un-obvious > to the user that it effectively acts as a filter switch --- in fact a > de-filtering switch, because the lack of -C is what filters out the > DATABASE item. > > I'm inclined to think that we should document that the output of -l > is restricted by -n and similar switches, but change the code so that > -C doesn't affect -l output. Comments? > Sounds good. -L could do with some man page help as well; --use-list=list-file Restore elements in list-file only, and in the order they appear in the file. Lines can be moved and can also be commented out by placing a ; at the start of the line. (See below for examples.) That indicates that "list-file only" lacks clarity when you can further restrict with command line parameters. Thanks Russell -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3563: DATESTYLE feature suggestion
i apologize for bringing this up from over 2 years ago but i haven't been able to find how this issue was resolved. the following is from the ecmascript 5 specification at http://www.ecmascript.org/docs/tc39-2009-043.pdf page 168: 15.9.1.15 Date Time String Format ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: -MM-DDTHH:mm:ss.sssZ ecmascript 5 is the most recent specification for JavaScript and i would think that having a DATESTYLE format to simplify interoperability with JavaScript applications would be highly desirable. simplifying interoperability could be achieved by either providing a new format that matched this specific format or by allowing a way to specify a custom DATESTYLE format. being able to specify a custom DATESTYLE format would be preferred since it is the more flexible option. perhaps this is already possible but i just haven't managed to find it. any help appreciated. thanks, ben... On Aug 21, 2007, at 7:53 PM, Randolf Richardson wrote: The following bug has been logged online: Bug reference: 3563 Logged by: Randolf Richardson Email address: randolf+postgresql@inter-corporate.com PostgreSQL version: 8.2.4 Operating system: NetBSD 4 (beta), NetBSD 3.1, NetWare 6.5 Description:DATESTYLE feature suggestion Details: After convincing clients and colleagues to switch from Oracle (and others) to PostgreSQL, an issue that comes up is the need to customize DATESTYLE. Because this isn't possible, the developers who were against the move to PostgreSQL make it political and recommended work-around solutions such as using to_char() or implementing a view for each table that contain TIMESTAMP[TZ]s is very difficult to argue with management because a lot of time is required to implement these items. In a future version, to solve this problem, an additional DATESTYLE option that uses the same rules as the to_char() function for date formatting would solve this problem. Here's an example: SET DATESTYLE = 'Custom -Mon-DD'; This feature would not only resolve this particular political strife, but would also solve many other problems, including simplifying coding for raw SQL output serving as reports (e.g., users still get confused about dates like "2007-06-03," wondering if they refer to June 3rd, or March 6th). I'm hoping that this suggestion will be an easy one to implement. Thanks in advance. P.S.: I searched around for a "feature suggestions" page but couldn't find it (if one exists, it should be linked to from the "Report a Bug" page). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3563: DATESTYLE feature suggestion
Hello 2010/5/16 Ben Hockey : > i apologize for bringing this up from over 2 years ago but i haven't been > able to find how this issue was resolved. it isn't bug, but request for new feature. look on http://wiki.postgresql.org/wiki/Developer_FAQ I have nothing against some new datestyles - xml, ecma5 and I am able to add to pg when hackers will agree Parametrised datestyle is little bit different. I know so it can be used for SQL injection on Oracle. So I am not sure if it is a good idea. But isn't problem create external project (maybe on pgFoundry) for customized datatype. Regards Pavel Stehule > > the following is from the ecmascript 5 specification at > http://www.ecmascript.org/docs/tc39-2009-043.pdf page 168: > >> 15.9.1.15 Date Time String Format >> ECMAScript defines a string interchange format for date-times based upon a >> simplification of the ISO 8601 >> Extended Format. The format is as follows: -MM-DDTHH:mm:ss.sssZ > > > ecmascript 5 is the most recent specification for JavaScript and i would > think that having a DATESTYLE format to simplify interoperability with > JavaScript applications would be highly desirable. simplifying > interoperability could be achieved by either providing a new format that > matched this specific format or by allowing a way to specify a custom > DATESTYLE format. being able to specify a custom DATESTYLE format would be > preferred since it is the more flexible option. > > perhaps this is already possible but i just haven't managed to find it. any > help appreciated. > > thanks, > > ben... > > On Aug 21, 2007, at 7:53 PM, Randolf Richardson wrote: > >> >> The following bug has been logged online: >> >> Bug reference: 3563 >> Logged by: Randolf Richardson >> Email address: randolf+postgresql@inter-corporate.com >> PostgreSQL version: 8.2.4 >> Operating system: NetBSD 4 (beta), NetBSD 3.1, NetWare 6.5 >> Description: DATESTYLE feature suggestion >> Details: >> >> After convincing clients and colleagues to switch from Oracle (and others) >> to PostgreSQL, an issue that comes up is the need to customize DATESTYLE. >> Because this isn't possible, the developers who were against the move to >> PostgreSQL make it political and recommended work-around solutions such as >> using to_char() or implementing a view for each table that contain >> TIMESTAMP[TZ]s is very difficult to argue with management because a lot of >> time is required to implement these items. >> >> In a future version, to solve this problem, an additional DATESTYLE option >> that uses the same rules as the to_char() function for date formatting >> would >> solve this problem. Here's an example: >> >> SET DATESTYLE = 'Custom -Mon-DD'; >> >> This feature would not only resolve this particular political strife, but >> would also solve many other problems, including simplifying coding for raw >> SQL output serving as reports (e.g., users still get confused about dates >> like "2007-06-03," wondering if they refer to June 3rd, or March 6th). >> >> I'm hoping that this suggestion will be an easy one to implement. >> >> Thanks in advance. >> >> P.S.: I searched around for a "feature suggestions" page but couldn't >> find >> it (if one exists, it should be linked to from the "Report a Bug" page). > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
