Re: [GENERAL] Is PL-PGSQL interpreted or complied?

2017-07-06 2:10 GMT+02:00 Tim Uckun : > I am curious about the stored proc languages inside of postgres. When I > write a stored proc is it compiled to some internal representation or just > interpreted? How does this work with other languages? > The PLpgSQL proc are saved in

Re: [GENERAL] Imperative Query Languages

From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Jason Dusek SQL is great and I am fully on board with the idea. Everywhere I go, I promote the greatness of SQL, of the relational model, and of Postgres. I didn’t write in so much to challenge

Re: [GENERAL] Is PL-PGSQL interpreted or complied?

On 7/5/2017 5:10 PM, Tim Uckun wrote: I am curious about the stored proc languages inside of postgres. When I write a stored proc is it compiled to some internal representation or just interpreted? plpgsql is interpreted directly, I don't believe its even pre-tokenized. How does this work

Re: Fwd: [GENERAL] Streaming replication bandwith per table

Thank you. Maybe it would help, but recently I had another issue with the tables having large arrays. I likely will redesign that part of the application, and I’ll see if it helps as a side effect. On Thu, Jun 22, 2017 at 5:55 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: >

Re: [GENERAL] Imperative Query Languages

On Wed, 5 Jul 2017 at 14:36 Peter Geoghegan p...@bowt.ie wrote: However, the OP seemed to be describing something that maps imperative > code to a declarative SQL query or something equivalent, which isn't > quite the same thing. The declarative nature of SQL feels

[GENERAL] Is PL-PGSQL interpreted or complied?

I am curious about the stored proc languages inside of postgres. When I write a stored proc is it compiled to some internal representation or just interpreted? How does this work with other languages? Also would it be possible to extract PL-PGSQL into a standalone (albeit crippled) language? Is

Re: [GENERAL] Imperative Query Languages

On Wed, Jul 5, 2017 at 7:02 AM, Merlin Moncure wrote: > Downthread, Tom mentions CODASYL, etc, but could have mentioned the > big daddy, ISAM, and all it's various flavors. Virtually all business > code was written using it (and much of it still is) leading into the > SQL

[GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

Hello, I am upgrading PostgreSQL 8.4 to 9.5 on Windows. There is some issue related to locale. Details are as follows: The steps that I am following are: 1. Install PostgreSQL 9.5 (8.4 is already installed). 2. Migrate data from 8.4's data dir to 9.5's data dir using pg_upgrade utility. 3.

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

On 07/05/2017 08:31 AM, Hans Schou wrote: 2017-07-05 15:41 GMT+02:00 Adrian Klaver >: [scheme[<+>dsn]]://[[username[:[password]]@][host][:port][/[dbname][/[[table[/[column[,column...]*]]]|sql]]]

Re: [SPAM] [GENERAL] How to install pgadmin3 or pgadmin4 on linux machine

On Wed, Jul 5, 2017 at 6:29 PM, Adrian Klaver wrote: > On 07/05/2017 05:25 AM, PAWAN SHARMA wrote: > >> >> > >> Hi Moreno, >> >> >> Thanks for response. >> >> 1. We don't have yum working on servers >> 2. We are using rpm to install postgres. >> >> >> We downloading

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

r...@bb-c.de (Rainer J.H. Brandt) writes: > Tom Lane writes: >> The whole thing's odd though --- certainly many people are building >> PG successfully on macOS. There's got to be something unusual about >> Rainer's build environment, but what? > I thought so, too, but I'm beginning to doubt it.

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Melvin, * Melvin Davidson (melvin6...@gmail.com) wrote: > On Wed, Jul 5, 2017 at 10:14 AM, Stephen Frost wrote: > >Part of my concern is that such a script is unlikely to show any problems > until it comes time to do a restore > As previously stated, the script was used to

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

On Wed, Jul 5, 2017 at 10:14 AM, Stephen Frost wrote: > Greetings, > > * Melvin Davidson (melvin6...@gmail.com) wrote: > > Stephen, > > >This script is a good example of why trying to take a PG backup using > > shell scripts isn't a good idea. > > > > Your criticism is noted,

Re: [GENERAL] Strange case of database bloat

On Tue, Jul 4, 2017 at 10:18 PM, Chris Travers wrote: > > Questions > === > I assume that it is the fact that rows update frequently which is the > problem here? But why doesn't Postgres re-use any of the empty disk pages? > Can you install the contrib extension

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

2017-07-05 15:41 GMT+02:00 Adrian Klaver : > > [scheme[<+>dsn]]://[[username[:[password]]@][host][:port][/[ > dbname][/[[table[/[column[,column...]*]]]|sql]]] > ^ > > The thing is that in a quick search on this I did not find a

Re: [SPAM] Re: [GENERAL] Invalid field size

Il 05/07/2017 16:33, Adrian Klaver ha scritto: On 07/05/2017 01:05 AM, Moreno Andreo wrote: Il 04/07/2017 20:51, Daniel Verite ha scritto: Tom Lane wrote: Moreno Andreo writes: So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a

Re: [GENERAL] Re: Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

2017-07-05 16:29 GMT+02:00 Thomas Kellerer : > Hans Schou schrieb am 05.07.2017 um 14:27: > > The dburl (or dburi) has become common to use by many systems > > connecting to a database. The feature is that one can pass all > > parameters in a string, which has similar pattern

Re: [GENERAL] building extension with large string inserts

On Wed, Jul 5, 2017 at 8:04 AM, Tom van Tilburg wrote: > I think I misunderstand. How would that help my insert statement? > You would get INSERT INTO mytable VALUES ($ javascript with a lot of > unescaped characters like /n " // etc. $); > ​Tom Lane provided the

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

2017-07-05 15:15 GMT+02:00 Albe Laurenz : > > Unless I misunderstand, this has been in PostgreSQL since 9.2: > Sorry! I did not read the *new* manual. (OK, 9.2 is not that new) It is even mentioned in the man page. Then I have a new proposal. Write a note about in

Re: [GENERAL] building extension with large string inserts

You are right! I totally forgot about this dollar quoting :) Typically one of those things you will only remember the hard way ;-) Thanks a lot, Tom On Wed, Jul 5, 2017 at 5:08 PM, Tom Lane wrote: > Tom van Tilburg writes: > > I think I

Re: [GENERAL] building extension with large string inserts

Tom van Tilburg writes: > I think I misunderstand. How would that help my insert statement? > You would get INSERT INTO mytable VALUES ($ javascript with a lot of > unescaped characters like /n " // etc. $); Sure, but in a dollar-quoted literal you don't need to escape

Re: [GENERAL] building extension with large string inserts

I think I misunderstand. How would that help my insert statement? You would get INSERT INTO mytable VALUES ($ javascript with a lot of unescaped characters like /n " // etc. $); and: Am I correct that INSERTS are the way to go in extensions? Best, Tom vT. On Wed, Jul 5, 2017 at 4:57 PM, Tom

Re: [GENERAL] building extension with large string inserts

Tom van Tilburg writes: > I am trying to build an extension where there is the need to insert large > strings consisting of javascript code. > ... > What would be a proper way to get this code into a table via an extension? > I've been working on generating INSERT

Re: [GENERAL] Invalid field size

On 07/05/2017 01:05 AM, Moreno Andreo wrote: Il 04/07/2017 20:51, Daniel Verite ha scritto: Tom Lane wrote: Moreno Andreo writes: So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a newline-conversion problem, compressed pg_dump

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

On 07/04/2017 11:56 PM, Rainer J.H. Brandt wrote: Tom Lane writes: Adrian Klaver writes: On 07/04/2017 01:29 PM, Rainer J.H. Brandt wrote: Good to know. I removed those options and tried again. Did you run make clean before re-running ./configure? Personally

[GENERAL] Re: Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

Hans Schou schrieb am 05.07.2017 um 14:27: > The dburl (or dburi) has become common to use by many systems > connecting to a database. The feature is that one can pass all > parameters in a string, which has similar pattern as http-URI do. > > Especially when using psql in a script, having the

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Greetings, * Melvin Davidson (melvin6...@gmail.com) wrote: > Stephen, > >This script is a good example of why trying to take a PG backup using > shell scripts isn't a good idea. > > Your criticism is noted, however, I have used it many times in the past > with absolutely no problem. I submitted

Re: [GENERAL] Strange case of database bloat

On Wed, Jul 5, 2017 at 3:51 PM, Bill Moran wrote: > On Wed, 5 Jul 2017 13:28:29 +0200 > Chris Travers wrote: > > > On Wed, Jul 5, 2017 at 1:00 PM, PT wrote: > > > > > 2x the working size for a frequently updated table

Re: [GENERAL] Imperative Query Languages

On Wed, Jul 5, 2017 at 12:22 AM, Jason Dusek wrote: > Hi All, > > This more of a general interest than specifically Postgres question. Are > there any “semi-imperative” query languages that have been tried in the > past? I’m imagining a language where something like this:

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

On Wed, Jul 5, 2017 at 10:47 PM, Melvin Davidson wrote: > Your criticism is noted, however, I have used it many times in the past with > absolutely no problem. Plug off the server on which is stored the backup just after your script finishes, you have a good chance to be

Re: [GENERAL] Strange case of database bloat

On Wed, 5 Jul 2017 13:28:29 +0200 Chris Travers wrote: > On Wed, Jul 5, 2017 at 1:00 PM, PT wrote: > > > 2x the working size for a frequently updated table isn't terrible bloat. > > Or are > > you saying it grows 2x every 24 hours and keeps

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Stephen, >This script is a good example of why trying to take a PG backup using shell scripts isn't a good idea. Your criticism is noted, however, I have used it many times in the past with absolutely no problem. I submitted that script as a possible solution to the op's problem/question. If you

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

On 07/05/2017 06:15 AM, Albe Laurenz wrote: Hans Schou wrote: The dburl (or dburi) has become common to use by many systems connecting to a database. The feature is that one can pass all parameters in a string, which has similar pattern as http-URI do. Especially when using psql in a script,

[GENERAL] building extension with large string inserts

I am trying to build an extension where there is the need to insert large strings consisting of javascript code. The easiest way to get these string currently into a table is by using \set varname `cat mycode.js` INSERT INTO mytable VALUES (:'varname'); and run this from the psql client. psql

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

Hans Schou wrote: > The dburl (or dburi) has become common to use by many systems connecting to a > database. > The feature is that one can pass all parameters in a string, which has > similar pattern as > http-URI do. > > Especially when using psql in a script, having the credentials in one

Re: [GENERAL] pg_start/stop_backup non-exclusive scripts to snapshot

Greetings, * Melvin Davidson (melvin6...@gmail.com) wrote: > On Tue, Jul 4, 2017 at 5:55 PM, Stephen Frost wrote: > > I'd recommend considering one of the existing PG backup tools which know > > how to properly perform WAL archiving and tracking the start/stop points > > in

Re: [GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

## Hans Schou (hans.sc...@gmail.com): > Example of usage: > psql pgsql://joe:p4zzw...@example.org:2345/dbname Make the scheme "postgresql" and you're here: https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING "32.1.1.2. Connection URIs". Regards, Christoph --

Re: [SPAM] [GENERAL] How to install pgadmin3 or pgadmin4 on linux machine

On 07/05/2017 05:25 AM, PAWAN SHARMA wrote: Hi Moreno, Thanks for response. 1. We don't have yum working on servers 2. We are using rpm to install postgres. We downloading postgresql standard rpm from EDB site. That is not what you said in your first post: "

Re: [GENERAL] [ADMIN] How to install pgadmin3 or pgadmin4 on linux machine

Hi, On Wed, 2017-07-05 at 17:05 +0530, PAWAN SHARMA wrote: > Please help me to install pgadmin3 or pgadmin4 on Redhat server. > > > https://yum.postgresql.org/repopackages.php#pg95 > > I have download pgdg-redhat95-9.5-3.noarch.rpm from the above link and > install successfully on my server.

[GENERAL] Feature proposal, DBURL: psql pgsql://joe:p4zzw...@example.org:2345/dbname

Hi The dburl (or dburi) has become common to use by many systems connecting to a database. The feature is that one can pass all parameters in a string, which has similar pattern as http-URI do. Especially when using psql in a script, having the credentials in one string is convenient. The syntax

Re: [SPAM] [GENERAL] How to install pgadmin3 or pgadmin4 on linux machine

On Jul 5, 2017 17:40, "Moreno Andreo" wrote: Il 05/07/2017 13:35, PAWAN SHARMA ha scritto: Hi All, Please help me to install pgadmin3 or pgadmin4 on Redhat server. https://yum.postgresql.org/repopackages.php#pg95 I have download pgdg-redhat95-9.5-3.noarch.rpm from

Re: [SPAM] [GENERAL] How to install pgadmin3 or pgadmin4 on linux machine

Il 05/07/2017 13:35, PAWAN SHARMA ha scritto: Hi All, Please help me to install

Re: [GENERAL] Strange case of database bloat

On Wed, Jul 5, 2017 at 7:28 AM, Chris Travers wrote: > > > On Wed, Jul 5, 2017 at 1:00 PM, PT wrote: > >> >> 2x the working size for a frequently updated table isn't terrible bloat. >> Or are >> you saying it grows 2x every 24 hours and keeps

[GENERAL] How to install pgadmin3 or pgadmin4 on linux machine

Hi All, Please help me to install pgadmin3 or pgadmin4 on Redhat server. https://yum.postgresql.org/repopackages.php#pg95 I have download pgdg-redhat95-9.5-3.noarch.rpm from the above link and install successfully on my server. what next how to configure it? Using PostgreSQL Version : 9.5.7

Re: [GENERAL] Strange case of database bloat

On Wed, Jul 5, 2017 at 1:00 PM, PT wrote: > > 2x the working size for a frequently updated table isn't terrible bloat. > Or are > you saying it grows 2x every 24 hours and keeps growing? The real question > is > how often the table is being vacuumed. How long have you

Re: [GENERAL] Strange case of database bloat

On Wed, 5 Jul 2017 07:18:03 +0200 Chris Travers wrote: > Hi; > > First, I haven't seen major problems of database bloat in a long time which > is why I find this case strange. I wanted to ask here what may be causing > it. > > Problem: > == > Database is in

Re: [GENERAL] Invalid field size

Il 04/07/2017 20:51, Daniel Verite ha scritto: Tom Lane wrote: Moreno Andreo writes: So the hint is to abandon manual COPY and let pg_dump do the hard work? If it is a newline-conversion problem, compressed pg_dump archives would be just as subject to

Re: [GENERAL] Imperative Query Languages

On Tue, 4 Jul 2017 at 23:57 Chris Travers chris.trav...@gmail.com wrote: I am curious where you see LINQ as starting at an imperative syntax. > The imperative integration is thin, I admit — it just the integration with for loops. Here's a good case that

Re: [GENERAL] Imperative Query Languages

On Wed, Jul 5, 2017 at 8:42 AM, Jason Dusek wrote: > > > If we imagine network databases have one layer: > > Imperative Plan > > And SQL databases have two: > > Declarative Query -> Imperative Plan > > It seems reasonable to say, LINQ, have three: > > Imperative

Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12

Tom Lane writes: > Adrian Klaver writes: > > On 07/04/2017 01:29 PM, Rainer J.H. Brandt wrote: > >> Good to know. I removed those options and tried again. > > > Did you run make clean before re-running ./configure? > > Personally I do "make distclean" before changing

Re: [GENERAL] Strange case of database bloat

On Wed, Jul 5, 2017 at 7:18 AM, Chris Travers wrote: > Hi; > > First, I haven't seen major problems of database bloat in a long time > which is why I find this case strange. I wanted to ask here what may be > causing it. > > Problem: > == > Database is in the

Re: [GENERAL] Imperative Query Languages

On Tue, 4 Jul 2017 at 23:01 Tom Lane wrote: > I'm pretty sure that that is the model that relational databases (and the > SQL language in particular) replaced, back in the 70s or so. Look up > "network" databases (eg CODASYL) and "hierarchical" DBs (eg IMS) for some >

Re: [GENERAL] Imperative Query Languages

On Wed, Jul 5, 2017 at 8:34 AM, Jason Dusek wrote: > > > I can not argue these points with you; but Fortress is a good example of > imperative looking code that translates to a functional/declarative core; > as indeed is monadic or applicative code. LINQ is a more recent

Re: [GENERAL] Imperative Query Languages

On Tue, 4 Jul 2017 at 23:22 Chris Travers wrote: > Having done a lot of SQL optimisation stuff I have doubts that this is > possible. The problem is that it is much easier to go from a declarative > to an imperative plan than it is to go the other way. In fact

Re: [GENERAL] Imperative Query Languages

On Wed, Jul 5, 2017 at 7:22 AM, Jason Dusek wrote: > Hi All, > > This more of a general interest than specifically Postgres question. Are > there any “semi-imperative” query languages that have been tried in the > past? I’m imagining a language where something like this: >

Re: [GENERAL] Imperative Query Languages

Jason Dusek writes: > This more of a general interest than specifically Postgres question. Are > there any “semi-imperative” query languages that have been tried in the > past? I’m imagining a language where something like this: > for employee in employees: > for