Re: [GENERAL] Xlogdump compiling error : undefined reference to `ber_sockbuf_io_udp'
On Wed, Feb 12, 2014 at 5:19 PM, Adarsh Sharma wrote: > Below link is little helpful :- > > http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-pg_xlogdump/ Postgres core includes pg_xlogdump since 9.3 and not xlogdump. As their outputs are a bit different you should directly contact the maintainer xlogdump if you begin playing with it. Saying that, I'd guess that the output of s/d/r means tablespace/database/relation. So if you cannot find those oids it means that they have been deleted at a point later than the record you are looking at. Regards, -- Michael -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_test_fsync: "Invalid argument" in the middle of a test
On Wed, Feb 12, 2014 at 10:46 PM, Alvaro Herrera wrote: > Would it be more useful to report the test as failed and continue with > other tests? Yeah, I think so, I'm planning to code this in the week. It's harder than it sounds because the alarm() timer is still ticking. On POSIX it can be cancelled with alarm(0), but the Windows code spawns a separate thread for timing. It seems that TerminateThread [1] could be used on Windows. It has many caveats, but should be safe for our purposes. Or we could only implement error handling on POSIX and call exit(1) on Windows. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms686717%28v=vs.85%29.aspx Regards, Marti -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_test_fsync: "Invalid argument" in the middle of a test
Bruce Momjian wrote: > On Tue, Feb 11, 2014 at 01:28:01AM +0200, Marti Raudsepp wrote: > > On Tue, Feb 11, 2014 at 12:20 AM, Marti Raudsepp wrote: > > > This is on Ubuntu 13.10 (kernel 3.11) with XFS (mount ed with noatime, > > > no other customizations). > > > > I managed to track this down; XFS doesn't allow using O_DIRECT for > > writes smaller than the filesystem's sector size (probably same on > > other FSes). The XFS filesystem created by the Ubuntu installer uses > > 4kB sectors, for some weird reason: > > I have added the attached, applied C comment about Direct I/O write > failures and mismatched block sizes. Would it be more useful to report the test as failed and continue with other tests? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_test_fsync: "Invalid argument" in the middle of a test
On Tue, Feb 11, 2014 at 01:28:01AM +0200, Marti Raudsepp wrote:
> On Tue, Feb 11, 2014 at 12:20 AM, Marti Raudsepp wrote:
> > This is on Ubuntu 13.10 (kernel 3.11) with XFS (mount ed with noatime,
> > no other customizations).
>
> I managed to track this down; XFS doesn't allow using O_DIRECT for
> writes smaller than the filesystem's sector size (probably same on
> other FSes). The XFS filesystem created by the Ubuntu installer uses
> 4kB sectors, for some weird reason:
I have added the attached, applied C comment about Direct I/O write
failures and mismatched block sizes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/contrib/pg_test_fsync/pg_test_fsync.c b/contrib/pg_test_fsync/pg_test_fsync.c
new file mode 100644
index 669c419..682821a
*** a/contrib/pg_test_fsync/pg_test_fsync.c
--- b/contrib/pg_test_fsync/pg_test_fsync.c
*** test_sync(int writes_per_op)
*** 369,374
--- 369,380
{
for (writes = 0; writes < writes_per_op; writes++)
if (write(tmpfile, buf, XLOG_BLCKSZ) != XLOG_BLCKSZ)
+ /*
+ * This can generate write failures if the filesystem
+ * has a large block size, e.g. 4k, and there is no
+ * support for O_DIRECT writes smaller than the
+ * file system block size, e.g. XFS.
+ */
die("write failed");
if (lseek(tmpfile, 0, SEEK_SET) == -1)
die("seek failed");
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
Leonardo M. Ramé writes: > On 2014-02-12 13:30:52 -0500, Tom Lane wrote: > >> Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= writes: >> > Hi, I'm trying to restore a database dump using pg_restore with the >> > following parameters: >> >> > pg_restore -h 127.0.0.1 -U _postgresql \ >> > -c -d postgres --exit-on-error \ >> > my_dump.backup >> >> > Note I used "\" to wrap the command, but the real one does not have >> > those. >> >> > pg_restore: [archiver (db)] Error while PROCESSING TOC: >> > pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK >> > CONSTRAINT fkidturno postgres >> > pg_restore: [archiver (db)] could not execute query: ERROR: relation >> > "public.turnodocumento" does not exist >> > Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT >> > fkidturno; >> >> > Why is this happening?, should I change the command I'm using to create >> > the backup?. >> >> The -c switch causes pg_restore to try to DROP every object it's about to >> restore. If you're restoring into an empty database then this is useless, >> and in fact will not work if you're also using --exit-on-error. Remove >> one or the other switch. >> >> Now, if you expected that all the objects do exist in the target database, >> then it might be worth inquiring a bit more closely into what's happening. >> >> regards, tom lane > > Tom, I've dropped the db, then createdb again, then removed the -c > option, now I get this error: > > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 735; 2612 213488 > PROCEDURAL LANGUAGE plpgsql postgres > pg_restore: [archiver (db)] could not execute query: ERROR: language > "plpgsql" already exists > Command was: CREATE PROCEDURAL LANGUAGE plpgsql; You can ignore that. Just make sure you're doing the loading auto-commit and without ON_ERROR_STOP set. Of course, you could drop lang plpgsql from your new DB and try again which, if that was going to be your only error, you may then run clean. HTH > > > -- > Leonardo M. Ramé > Medical IT - Griensu S.A. > Av. Colón 636 - Piso 8 Of. A > X5000EPT -- Córdoba > Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 > Cel.: +54 9 (011) 40871877 -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consult...@comcast.net p: 312.241.7800 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Pg_trgm and "invalid invalid byte sequence for encoding UTF8"
Hello experts, I want to compare integer arrays basically with methods based on string similarity (i.e., levenshtein, trigrams etc).. In order to do that I hacked a custom function that converts those integer array to strings, where each integer is converted to a character by the function CHR(my_array1[i]+64) (so that 1->A, 2 ->B etc). This hack of course for large integers (I have integers up to 300,000) probably creates invalid UTF-8 characters. Levenshtein (from fuzzystrmatch module) does not seem to have a problem with that and works perfectly, since it is based on just comparing UTF8 codes. On the other hand when I try similarity function array1<->array1 for some cases it works (I think it works for all integers up to 4096) but for some larger indexes I get invalid byte sequence for encoding "UTF8" errors: Example integer sequence "8527,63586,8526,63585,63584,63583,63582,8525,8760,63820,63821,63822,860,57610,861,57611,862,57612,57613,863,57614,57615,57616,39850,39851,39852,39853,39854,39855,95275,39856,39857,95276,95277,39858,95278,95279,39859,95280,39860,95281,95282,39861,39862,39863,95283,95284,27095,27096,82406,82407,27097,27098,27099,27100,82408,27101,27102,27103,25702,80837,25703,25704,80838,25705,25706,25707,25708,30011,85343,30012,85344,30013,30014,51019,48260,48261,56809,56810,56811,56812,113829,31762,87568,31763,45925,41778,41779,41780,31778,31779,87571}"; Error message: invalid byte sequence for encoding "UTF8": 0xed 0xb8 0xa9 Is there a way to suppress these errors similar to levenshtein which does not care about validity of UTF characters? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Pg-trgm-and-invalid-invalid-byte-sequence-for-encoding-UTF8-tp5791681.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
On 2014-02-12 14:04:41 -0500, Tom Lane wrote: > Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= writes: > > On 2014-02-12 13:30:52 -0500, Tom Lane wrote: > >> The -c switch causes pg_restore to try to DROP every object it's about to > >> restore. If you're restoring into an empty database then this is useless, > >> and in fact will not work if you're also using --exit-on-error. Remove > >> one or the other switch. > > > Tom, I've dropped the db, then createdb again, then removed the -c > > option, now I get this error: > > > pg_restore: [archiver (db)] Error while PROCESSING TOC: > > pg_restore: [archiver (db)] Error from TOC entry 735; 2612 213488 > > PROCEDURAL LANGUAGE plpgsql postgres > > pg_restore: [archiver (db)] could not execute query: ERROR: language > > "plpgsql" already exists > > Command was: CREATE PROCEDURAL LANGUAGE plpgsql; > > pg_dump versions more recent than 8.4 use "CREATE OR REPLACE PROCEDURAL > LANGUAGE" to work around the possibility that plpgsql is preinstalled. > If you don't want to use a modern pg_dump, you'll need to not use > --exit-on-error. > > In general, it's recommended to use the newer pg_dump when trying to > transfer data from an older installation to a newer one. You can > generally make it work without that, but it's not necessarily going > to be seamless, and one of the ways it tends to not be seamless is > that you have to be willing to ignore harmless errors. > Ok, I understand your reasoning. Removing -c and --exit-on-error fixed the issue. BTW, I've used --exit-on-error because there were many errors, and I wanted to fix each one of them. Regards, -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= writes: > On 2014-02-12 13:30:52 -0500, Tom Lane wrote: >> The -c switch causes pg_restore to try to DROP every object it's about to >> restore. If you're restoring into an empty database then this is useless, >> and in fact will not work if you're also using --exit-on-error. Remove >> one or the other switch. > Tom, I've dropped the db, then createdb again, then removed the -c > option, now I get this error: > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 735; 2612 213488 > PROCEDURAL LANGUAGE plpgsql postgres > pg_restore: [archiver (db)] could not execute query: ERROR: language > "plpgsql" already exists > Command was: CREATE PROCEDURAL LANGUAGE plpgsql; pg_dump versions more recent than 8.4 use "CREATE OR REPLACE PROCEDURAL LANGUAGE" to work around the possibility that plpgsql is preinstalled. If you don't want to use a modern pg_dump, you'll need to not use --exit-on-error. In general, it's recommended to use the newer pg_dump when trying to transfer data from an older installation to a newer one. You can generally make it work without that, but it's not necessarily going to be seamless, and one of the ways it tends to not be seamless is that you have to be willing to ignore harmless errors. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
On 2014-02-12 13:30:52 -0500, Tom Lane wrote: > Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= writes: > > Hi, I'm trying to restore a database dump using pg_restore with the > > following parameters: > > > pg_restore -h 127.0.0.1 -U _postgresql \ > > -c -d postgres --exit-on-error \ > > my_dump.backup > > > Note I used "\" to wrap the command, but the real one does not have > > those. > > > pg_restore: [archiver (db)] Error while PROCESSING TOC: > > pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK > > CONSTRAINT fkidturno postgres > > pg_restore: [archiver (db)] could not execute query: ERROR: relation > > "public.turnodocumento" does not exist > > Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT > > fkidturno; > > > Why is this happening?, should I change the command I'm using to create > > the backup?. > > The -c switch causes pg_restore to try to DROP every object it's about to > restore. If you're restoring into an empty database then this is useless, > and in fact will not work if you're also using --exit-on-error. Remove > one or the other switch. > > Now, if you expected that all the objects do exist in the target database, > then it might be worth inquiring a bit more closely into what's happening. > > regards, tom lane Tom, I've dropped the db, then createdb again, then removed the -c option, now I get this error: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 735; 2612 213488 PROCEDURAL LANGUAGE plpgsql postgres pg_restore: [archiver (db)] could not execute query: ERROR: language "plpgsql" already exists Command was: CREATE PROCEDURAL LANGUAGE plpgsql; -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
On 2014-02-12 09:51:10 -0800, Adrian Klaver wrote: > On 02/12/2014 09:41 AM, Leonardo M. Ramé wrote: > >Hi, I'm trying to restore a database dump using pg_restore with the > >following parameters: > > > >pg_restore -h 127.0.0.1 -U _postgresql \ > > -c -d postgres --exit-on-error \ > > my_dump.backup > > > >Note I used "\" to wrap the command, but the real one does not have > >those. > > > >pg_restore: [archiver (db)] Error while PROCESSING TOC: > >pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK > >CONSTRAINT fkidturno postgres > >pg_restore: [archiver (db)] could not execute query: ERROR: relation > >"public.turnodocumento" does not exist > > Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT > >fkidturno; > > > >Why is this happening?, should I change the command I'm using to create > >the backup?. > > Did you look in the restored database to see if everything is > correct or not? > > > What version of pg_dump did you use to do the pg_dump, the 8.4 or 9.2 one? > > It is recommended that you use the later version to dump older > databases as it can deal with any changes that have occurred. > > > > >To backup the database I'm using: > > > >pg_dump -Fc -h 127.0.0.1 -U postgres mydb > my_dump.backup > > > >P.S.: the original db is PostgreSql 8.4, the target is 9.2 > > > >Regards, > > > Thanks Adrian, but I cannot use a newer pg_dump version because I cannot upgrade it inside the remote server, also, as the db is very large I prefer to do the backup internally and rsync the file. -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= writes: > Hi, I'm trying to restore a database dump using pg_restore with the > following parameters: > pg_restore -h 127.0.0.1 -U _postgresql \ > -c -d postgres --exit-on-error \ > my_dump.backup > Note I used "\" to wrap the command, but the real one does not have > those. > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK > CONSTRAINT fkidturno postgres > pg_restore: [archiver (db)] could not execute query: ERROR: relation > "public.turnodocumento" does not exist > Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT > fkidturno; > Why is this happening?, should I change the command I'm using to create > the backup?. The -c switch causes pg_restore to try to DROP every object it's about to restore. If you're restoring into an empty database then this is useless, and in fact will not work if you're also using --exit-on-error. Remove one or the other switch. Now, if you expected that all the objects do exist in the target database, then it might be worth inquiring a bit more closely into what's happening. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Hard upgrade (everything)
On Thu, Feb 6, 2014 at 10:07:18AM +0100, Rémi Cura wrote: > On my private computer I upgraded first the postgres to 9.3, then upgraded > postgis. > Sadly according to http://trac.osgeo.org/postgis/wiki/ > UsersWikiPostgreSQLPostGIS , > postgis 1.5 is not compatible with postgres 9.3. > However POstgis 2.1 is compatible with you current postgres option. > So as suggested you can upgrade postgis (see hard/soft upgrade), the upgrade > postgres. > By the way postgis is very easy to compil with ubuntu (use package system to > get dependecies, then simply sudo ./autogen.sh, sudo ./configure, make , sudo > make install) Yes, that is the order I have head. You can upgrade postgis from 1.5 to 2.1 on the old server, then use pg_upgrade to upgrade Postgres. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_restore issue
On 02/12/2014 09:41 AM, Leonardo M. Ramé wrote: Hi, I'm trying to restore a database dump using pg_restore with the following parameters: pg_restore -h 127.0.0.1 -U _postgresql \ -c -d postgres --exit-on-error \ my_dump.backup Note I used "\" to wrap the command, but the real one does not have those. pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK CONSTRAINT fkidturno postgres pg_restore: [archiver (db)] could not execute query: ERROR: relation "public.turnodocumento" does not exist Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT fkidturno; Why is this happening?, should I change the command I'm using to create the backup?. Did you look in the restored database to see if everything is correct or not? What version of pg_dump did you use to do the pg_dump, the 8.4 or 9.2 one? It is recommended that you use the later version to dump older databases as it can deal with any changes that have occurred. To backup the database I'm using: pg_dump -Fc -h 127.0.0.1 -U postgres mydb > my_dump.backup P.S.: the original db is PostgreSql 8.4, the target is 9.2 Regards, -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pg_restore issue
Hi, I'm trying to restore a database dump using pg_restore with the following parameters: pg_restore -h 127.0.0.1 -U _postgresql \ -c -d postgres --exit-on-error \ my_dump.backup Note I used "\" to wrap the command, but the real one does not have those. pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 3156; 2606 432226 FK CONSTRAINT fkidturno postgres pg_restore: [archiver (db)] could not execute query: ERROR: relation "public.turnodocumento" does not exist Command was: ALTER TABLE ONLY public.turnodocumento DROP CONSTRAINT fkidturno; Why is this happening?, should I change the command I'm using to create the backup?. To backup the database I'm using: pg_dump -Fc -h 127.0.0.1 -U postgres mydb > my_dump.backup P.S.: the original db is PostgreSql 8.4, the target is 9.2 Regards, -- Leonardo M. Ramé Medical IT - Griensu S.A. Av. Colón 636 - Piso 8 Of. A X5000EPT -- Córdoba Tel.: +54(351)4246924 +54(351)4247788 +54(351)4247979 int. 19 Cel.: +54 9 (011) 40871877 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] function with different return type depending on parameter?
On Wed, Feb 12, 2014 at 9:24 AM, Tom Lane wrote: > James Harper writes: >> is it possible to have a function that can return a different type >> depending on the parameters? > > The data type of any expression (including a function call) has to be > determinable at parse time, so no you can't just randomly return a > run-time-determined data type. > > However, have you looked at the "polymorphic functions" feature? > You can declare a function as returning the same data type that > one of its inputs has. This seems to cover most of the cases > that are useful in practice. > > http://www.postgresql.org/docs/9.3/static/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC > http://www.postgresql.org/docs/9.3/static/xfunc-sql.html#AEN52916 You can also define a function to return 'text', which by virtue of every other type being able to be casted to/from text, can be used as a kind of variant. This technique is pretty dubious mostly, but can occasionally be used to work around problematic situations. There's also hstore for dealing with record-variant situations (this is especially useful in, say, auditing triggers), and it's emerging strong contender: json. All of the text variant approaches though simply defer the type resolution to some later point, which can lead to performance and logical consistency issues if you're not careful. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgsql and asciidoc output
On 2/11/14, 6:25 PM, Vik Fearing wrote: > I personally find Markdown to be more pleasing to the eye than AsciiDoc. Markdown can embed HTML tables, so there is nothing that we need to implement. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] function with different return type depending on parameter?
James Harper writes: > is it possible to have a function that can return a different type > depending on the parameters? The data type of any expression (including a function call) has to be determinable at parse time, so no you can't just randomly return a run-time-determined data type. However, have you looked at the "polymorphic functions" feature? You can declare a function as returning the same data type that one of its inputs has. This seems to cover most of the cases that are useful in practice. http://www.postgresql.org/docs/9.3/static/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC http://www.postgresql.org/docs/9.3/static/xfunc-sql.html#AEN52916 regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgsql and asciidoc output
On Wed, Feb 12, 2014 at 08:48:49AM +0100, Gabriele Bartolini wrote: > I second Bruce. I massively use asciidoc. I guess adding both asciidoc and md > would not be too hard. Agreed. Assuming there are no objections, I will add it to the TODO list. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgsql and asciidoc output
On Wed, Feb 12, 2014 at 06:02:29AM +0100, Pavel Stehule wrote: > Perhaps, but if we're going to add a text markup format then we'll have > to choose one out of many. > > I personally find Markdown to be more pleasing to the eye than AsciiDoc. > http://en.wikipedia.org/wiki/Markdown > > > Markdown is really well know now, and can be useful - but there is small > differences between implementations - wikipedia, github, jira > but implementation can be really nice OK, great. Would the markdown implementation differences affect the psql table output, or are the differences in things we don't need to worry about? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgsql and asciidoc output
On Tue, Feb 11, 2014 at 03:32:32PM -0800, Steve Atkins wrote: > > On Feb 11, 2014, at 2:56 PM, Bruce Momjian wrote: > > > Someone suggested that 'asciidoc' > > (http://en.wikipedia.org/wiki/AsciiDoc) would be a good output format > > for psql, similar to the existing output formats of html, latex, and > > troff. > > > > Would this be useful? > > Less so than Markdown[1], IMO. (Or CSV or xlsx, come to that.) > > There’s a long list of potentially useful output formats. How pluggable > is the output formatter? It isn't hard to add new formats --- you are passed a table structure and you printf the output. Here is the HTML format output function: http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/print.c;h=79fc43eeda3330873acbea4ad1c555e051e81d00;hb=HEAD#l1394 I did the latex-longtable format for PG 9.3. The difficulty was understanding the latex-longtable format specification, not writing the C code. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Streaming Replication - Error on Standby
Thanks for the information and the URLs! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Streaming-Replication-Error-on-Standby-tp5791463p5791588.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pgsql and asciidoc output
> From: Bruce Momjian > To: PostgreSQL-general > Sent: Tuesday, 11 February 2014, 22:56 > Subject: [GENERAL] pgsql and asciidoc output > > Someone suggested that 'asciidoc' > (http://en.wikipedia.org/wiki/AsciiDoc) would be a good output format > for psql, similar to the existing output formats of html, latex, and > troff. > > Would this be useful? > Not sure about the arguments for and against either, but I'm rather fond of markdown (http://en.wikipedia.org/wiki/Markdown) > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + Everyone has their own god. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] function with different return type depending on parameter?
Hello no it is not possible Regards Pavel p.s. result - type must be known before execution (when execution plan is created) 2014-02-12 10:20 GMT+01:00 James Harper : > is it possible to have a function that can return a different type > depending on the parameters? Eg (approximately) > > if param = "one" then return 1 > if param = "two" then return "2" > if param = "three" then return 3.0 > etc > > I can't see any variant type > > thanks > > James > > > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
Re: [GENERAL] function with different return type depending on parameter?
Hey http://www.postgresql.org/docs/9.3/static/plpgsql-declarations.html at anyelement. Cheers Rémi-C 2014-02-12 10:20 GMT+01:00 James Harper : > is it possible to have a function that can return a different type > depending on the parameters? Eg (approximately) > > if param = "one" then return 1 > if param = "two" then return "2" > if param = "three" then return 3.0 > etc > > I can't see any variant type > > thanks > > James > > > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
[GENERAL] function with different return type depending on parameter?
is it possible to have a function that can return a different type depending on the parameters? Eg (approximately) if param = "one" then return 1 if param = "two" then return "2" if param = "three" then return 3.0 etc I can't see any variant type thanks James -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Xlogdump compiling error : undefined reference to `ber_sockbuf_io_udp'
Below link is little helpful :- http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-pg_xlogdump/ Thanks
