Re: [GENERAL] Proper relational database?

[Raymond Brinzer]

Well, this hits very close to my feelings in several respects.  I
don't often bring this up, because I don't generally feel like "I
loathe SQL" is quite the thing to say in a community called
"PostgreSQL".  :-)  Or, "I really love this project... can we change
its direction entirely?"

But yeah, that's in my heart. And I'm quite in agreement on NoSQL. I
don't think a lot of people realize there *is* a difference between
"relational" and SQL, so the baby goes out with the bathwater.

As it just so happens, I actually hacked a Scheme interpreter into the
PostgreSQL parser, and got it to interpret incoming messages, with
virtually the same idea. I started messing with generating SQL from
S-expressions, with the idea to perhaps call query-building functions
later on.  I started off with Chibi Scheme, and moved to Chicken later
on, mostly because the folks in the Chicken IRC channel are so
helpful.  I was wondering whether PostgreSQL might consider supporting
alternative query languages, similar to the way it supports multiple
languages for stored procedures.  Ideally, it'd be nice to get the
query results as S-expressions also.

On Thu, Apr 21, 2016 at 4:36 PM, Guyren Howe  wrote:
> Anyone familiar with the issue would have to say that the tech world would be 
> a significantly better place if IBM had developed a real relational database 
> with an elegant query language rather than the awful camel of a thing that is 
> SQL.
>
> If I had a few $million to spend in a philanthropical manner, I would hire 
> some of the best PG devs to develop a proper relational database server. 
> Probably a query language that expressed the relational algebra in a 
> scheme-like syntax, and the storage model would be properly relational (eg no 
> duplicate rows).
>
> It's an enormous tragedy that all the development effort that has gone into 
> NoSQL database has pretty much all gotten it wrong: by all means throw out 
> SQL, but not the relational model with it. They're all just rehashing the 
> debate over hierarchical storage from the 70s. Comp Sci courses should 
> feature a history class.
>
> It's a bit odd to me that someone isn't working on such a thing.
>
> Just curious what folks here have to say…
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



-- 
Ray Brinzer


-- 
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] different empty array syntax requirements

[Tom Lane]

Scott Ribe  writes:
> How is that one pgsql build (both are 9.5.2) has different casting behavior 
> for empty arrays:
> pedcard=# select (ARRAY[])::text[];
> ERROR:  cannot determine type of empty array
> LINE 1: select (ARRAY[])::text[];
> ^
> HINT:  Explicitly cast to the desired type, for example ARRAY[]::integer[].

... wtf?

[ thinks for awhile ... ]

Oh!  I bet this explains it:

regression=#  select (ARRAY[])::text[];
 array 
---
 {}
(1 row)

regression=# set operator_precedence_warning = on;
SET
regression=#  select (ARRAY[])::text[];
ERROR:  cannot determine type of empty array
LINE 1: select (ARRAY[])::text[];
^
HINT:  Explicitly cast to the desired type, for example ARRAY[]::integer[].


The parens turn into an actual parsetree node when
operator_precedence_warning is on, and the cast-of-an-array hack doesn't
know it should look through such a node.  That's a bug.  Will fix it.

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] different empty array syntax requirements

[Alvaro Aguayo Garcia-Rada]

Looks like one has the appropiate cast operator, while the other hasn't. Have 
you tried doing the same, on both server, on an empty database created from 
template0?

Regards,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103  | RPC: (+51) 
954183248
Website: www.ocs.pe

Sent from my Sony Xperia™ smartphone

 Scott Ribe wrote 

How is that one pgsql build (both are 9.5.2) has different casting behavior for 
empty arrays:


ericmj=# select ARRAY[]::text[];
 array
---
 {}
(1 row)

ericmj=# select (ARRAY[])::text[];
 array
---
 {}
(1 row)


--VS--


pedcard=# select ARRAY[]::text[];
 array
---
 {}
(1 row)

pedcard=# select (ARRAY[])::text[];
ERROR:  cannot determine type of empty array
LINE 1: select (ARRAY[])::text[];
^
HINT:  Explicitly cast to the desired type, for example ARRAY[]::integer[].

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice







-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] different empty array syntax requirements

[Scott Ribe]

How is that one pgsql build (both are 9.5.2) has different casting behavior for 
empty arrays:


ericmj=# select ARRAY[]::text[];
 array
---
 {}
(1 row)

ericmj=# select (ARRAY[])::text[];
 array
---
 {}
(1 row)


--VS--


pedcard=# select ARRAY[]::text[];
 array
---
 {}
(1 row)

pedcard=# select (ARRAY[])::text[];
ERROR:  cannot determine type of empty array
LINE 1: select (ARRAY[])::text[];
^
HINT:  Explicitly cast to the desired type, for example ARRAY[]::integer[].

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice







-- 
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] Is it possible to call Postgres directly?

[david]

That's OK. I can set things up so that the Thrift or Web servers call the
Andl runtime directly, pass generated SQL queries in through libpq, and call
the Andl runtime recursively from the plandl handler as needed. It's just
one more API to deal with.

Thanks for the suggestion, but I already did an Sqlite implementation. It
was the obvious place to start, but now I need a real server.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org


> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Thursday, 21 April 2016 11:57 PM
> To: da...@andl.org
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Is it possible to call Postgres directly?
> 
>  writes:
> > So the question is: Can a C program link to the Postgres DLL and call
> > SPI directly, rather than through a language function?
> 
> No, there is no provision for non-server usage of the code.  If that's
what
> you're after you might be happier with SQLite or something similar.
> 
>   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] Update field to a column from another table

[drum.lu...@gmail.com]

The problem was a trigger in my DB, when I disabled it the data started to
be updated.


Lucas

Re: [GENERAL] disable ipv6?

[Adrian Klaver]

On 04/19/2016 06:35 PM, Jonathan Vanasco wrote:

I'm running postgresql on ubuntu.  the 9.4 branch from postgresql.org

I think the only way to disable ipv6 is to edit postgresql.conf and explicitly 
state localhost in ipv4 as follows

 - listen_addresses = 'localhost'
 + listen_addresses = '127.0.0.1'

can anyone confirm?


http://www.postgresql.org/docs/9.4/interactive/runtime-config-connection.html

"listen_addresses (string)

Specifies the TCP/IP address(es) on which the server is to listen 
for connections from client applications. The value takes the form of a 
comma-separated list of host names and/or numeric IP addresses. The 
special entry * corresponds to all available IP interfaces. The entry 
0.0.0.0 allows listening for all IPv4 addresses and :: allows listening 
for all IPv6 addresses. If the list is empty, the server does not listen 
on any IP interface at all, in which case only Unix-domain sockets can 
be used to connect to it. The default value is localhost, which allows 
only local TCP/IP "loopback" connections to be made. While client 
authentication (Chapter 19) allows fine-grained control over who can 
access the server, listen_addresses controls which interfaces accept 
connection attempts, which can help prevent repeated malicious 
connection requests on insecure network interfaces. This parameter can 
only be set at server start.

"









--
Adrian Klaver
adrian.kla...@aklaver.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] disable ipv6?

[Gavin Flower]

On 20/04/16 13:35, Jonathan Vanasco wrote:

I'm running postgresql on ubuntu.  the 9.4 branch from postgresql.org

I think the only way to disable ipv6 is to edit postgresql.conf and explicitly 
state localhost in ipv4 as follows

 - listen_addresses = 'localhost'
 + listen_addresses = '127.0.0.1'

can anyone confirm?





Curious, why do you want to disable IPv6 for local access?


Cheers,
Gavin


--
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] Update field to a column from another table

[Adrian Klaver]

On 04/21/2016 11:52 AM, drum.lu...@gmail.com wrote:

So when I run:

UPDATE ja_jobs t2
SET time_job = t1.time_job
FROM junk.ja_test t1
WHERE t2.id  = t1.id 
AND t2.time_job IS DISTINCT FROM t1.time_job;


I get:

UPDATE 2202

So I check the data by doing:

select * FROM public.ja_jobs WHERE id = 14574527


And the "time_job" field is null


First idea:

Are you doing this in two different sessions at the same time, so 
something like this?:


Session 1
BEGIN;
UPDATE ja_jobs t2
SET time_job = t1.time_job
FROM junk.ja_test t1
WHERE t2.id = t1.id
AND t2.time_job IS DISTINCT FROM t1.time_job;

Session 2
select * FROM public.ja_jobs WHERE id = 14574527


Where Session 2 is not seeing the UPDATE in Session 1 because the 
transaction has not been COMMITed.


Second idea:

Does id = 14574527 meet the criteria AND t2.time_job IS DISTINCT FROM 
t1.time_job?








--
Adrian Klaver
adrian.kla...@aklaver.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] Proper relational database?

[John McKown]

Just as a curiosity, what do you think of ANDL?

http://www.andl.org/welcome-to-andl/

The developer has been posting some questions here about interfacing it to
PostgreSQL. But he doesn't just want to do a "translate the ANDL language
to SQL language"

On Thu, Apr 21, 2016 at 3:36 PM, Guyren Howe  wrote:

> Anyone familiar with the issue would have to say that the tech world would
> be a significantly better place if IBM had developed a real relational
> database with an elegant query language rather than the awful camel of a
> thing that is SQL.
>
> If I had a few $million to spend in a philanthropical manner, I would hire
> some of the best PG devs to develop a proper relational database server.
> Probably a query language that expressed the relational algebra in a
> scheme-like syntax, and the storage model would be properly relational (eg
> no duplicate rows).
>
> It's an enormous tragedy that all the development effort that has gone
> into NoSQL database has pretty much all gotten it wrong: by all means throw
> out SQL, but not the relational model with it. They're all just rehashing
> the debate over hierarchical storage from the 70s. Comp Sci courses should
> feature a history class.
>
> It's a bit odd to me that someone isn't working on such a thing.
>
> Just curious what folks here have to say…
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
"He must have a Teflon brain -- nothing sticks to it"
Phyllis Diller

Maranatha! <><
John McKown

Re: [GENERAL] Proper relational database?

[David G. Johnston]

On Thu, Apr 21, 2016 at 1:36 PM, Guyren Howe  wrote:

> Anyone familiar with the issue would have to say that the tech world would
> be a significantly better place if IBM had developed a real relational
> database with an elegant query language rather than the awful camel of a
> thing that is SQL.
>
> If I had a few $million to spend in a philanthropical manner, I would hire
> some of the best PG devs to develop a proper relational database server.
> Probably a query language that expressed the relational algebra in a
> scheme-like syntax, and the storage model would be properly relational (eg
> no duplicate rows).
>
> It's an enormous tragedy that all the development effort that has gone
> into NoSQL database has pretty much all gotten it wrong: by all means throw
> out SQL, but not the relational model with it. They're all just rehashing
> the debate over hierarchical storage from the 70s. Comp Sci courses should
> feature a history class.
>
> It's a bit odd to me that someone isn't working on such a thing.
>
> Just curious what folks here have to say…
>

​Transpiling

​Having learned SQL you come to appreciate its warts and inefficiencies -
but I have no doubt that any other attempt at the same goal would have its
own, different, set of complaints.

​My tables don't have duplicates and while extra care need be taken
automatic duplicate removal also has the property of potentially hiding
bugs - whether more or less than non-removal I cannot say.

​David J.

Re: [GENERAL] Proper relational database?

[Peter Geoghegan]

On Thu, Apr 21, 2016 at 1:36 PM, Guyren Howe  wrote:
> If I had a few $million to spend in a philanthropical manner, I would hire 
> some of the best PG devs to develop a proper relational database server. 
> Probably a query language that expressed the relational algebra in a 
> scheme-like syntax, and the storage model would be properly relational (eg no 
> duplicate rows).

Have you heard of QUEL?

See https://en.wikipedia.org/wiki/QUEL_query_languages

-- 
Peter Geoghegan


-- 
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] zero length string to zero

[Adrian Klaver]

On 04/20/2016 05:31 AM, Shadi Mal wrote:

Hi,
  I get zero length string in my result but I want to have zero value
instead.
what can I do?
my query is:
SELECT unreadmandatory.id ,
  Count(unreadmandatory.course) AS nbrofmandatoryleft
FROM unreadmandatory
   GROUP BY unreadmandatory.id 


What is the type of unreadmandatory.id?

And are you getting an empty string or NULL?


--
Adrian Klaver
adrian.kla...@aklaver.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] Proper relational database?

[Guyren Howe]

Anyone familiar with the issue would have to say that the tech world would be a 
significantly better place if IBM had developed a real relational database with 
an elegant query language rather than the awful camel of a thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire some 
of the best PG devs to develop a proper relational database server. Probably a 
query language that expressed the relational algebra in a scheme-like syntax, 
and the storage model would be properly relational (eg no duplicate rows).

It's an enormous tragedy that all the development effort that has gone into 
NoSQL database has pretty much all gotten it wrong: by all means throw out SQL, 
but not the relational model with it. They're all just rehashing the debate 
over hierarchical storage from the 70s. Comp Sci courses should feature a 
history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Announcing BedquiltDB: A json doc-store built on PostgreSQL

[Shane Kilkelly]

Hi all,

For the last year I’ve been working on building a vaguely mongoldb-inspired API 
on top of the Postgres jsonb column types. The result is BedquiltDB 
(http://bedquiltdb.github.io/).

The Gist:

BedquiltDB is a vaguely mongodb-inspired json store built on top of 
PostgreSQL's jsonb column type. It does the things you'de expect, creating _id 
fields automatically, creating tables on the first write, etc.

It is implemented as a postgres extension (a horrible lump of PL/PgSQL), and 
client libraries for python, node and clojure.
While I'm not using it in production for anything, it is pretty well tested, 
and I had fun making it, which is what really matters :)

If you fancy stopping by for a chat, we have a room set up on gitter 
(https://gitter.im/BedquiltDB/bedquilt-core), and would love to hear any 
feedback on the project.

— — — — — —
Shane Kilkelly
e: sh...@kilkelly.me
w: shanekilkelly.net

[GENERAL] Background worker with Listen

[Ihnat Peter | TSS Group a . s .]

I am trying to create background worker which listens to notifications and do 
some work after receiving one.
I got 2 problems:

-  Worker is receiving notifications from every channel not only the 
registered channel (in my case "foo")

-  Notifications are not logged in the server log - I cannot store the 
payloads for further work
Any help is welcomed.

Here is the code:

PG_MODULE_MAGIC;

void _PG_init(void);
void _PG_fini(void);

static volatile sig_atomic_t got_sigterm = false;
static volatile sig_atomic_t got_sigusr1 = false;
static char *notify_database = NULL;
static emit_log_hook_type prev_log_hook = NULL;

static void
bgw_sigterm(SIGNAL_ARGS)
{
int save_errno = errno;
got_sigterm = true;
if (MyProc)
SetLatch(>procLatch);
errno = save_errno;
}

static void
bgw_sigusr1(SIGNAL_ARGS)
{
int save_errno = errno;
got_sigusr1 = true;
if (MyProc)
SetLatch(>procLatch);
   errno = save_errno;
}

static void
notify_main(Datum main_arg)
{
pqsignal(SIGTERM, bgw_sigterm);
pqsignal(SIGUSR1, bgw_sigusr1);

BackgroundWorkerUnblockSignals();
BackgroundWorkerInitializeConnection(notify_database, NULL);
 EnableNotifyInterrupt();

pgstat_report_activity(STATE_RUNNING, "background_worker");
StartTransactionCommand();
Async_Listen("foo");
CommitTransactionCommand();
pgstat_report_activity(STATE_IDLE, NULL);

while (!got_sigterm)
{
int   rc;

rc = WaitLatch(>procLatch, WL_LATCH_SET 
| WL_TIMEOUT | WL_POSTMASTER_DEATH, 1L);
ResetLatch(>procLatch);

if (rc & WL_POSTMASTER_DEATH)
proc_exit(1);

if (got_sigusr1)
{
got_sigusr1 = false;
elog(INFO, " background_worker: 
notification received");
// DO SOME WORK WITH STORED 
NOTIFICATIONS
}

}

elog(LOG, "background_worker: finished");
proc_exit(0);
}

static void
store_notification(ErrorData *edata)
{
// HERE STORE THE NOTIFICATION FROM SERVER LOG

if (prev_log_hook)
(*prev_log_hook) (edata);
}

void
_PG_init(void)
{
BackgroundWorker worker;
DefineCustomStringVariable("postgres", NULL, NULL, 
_database,
   "postgres",
   PGC_POSTMASTER, 0, NULL, NULL, NULL);

MemSet(, 0, sizeof(BackgroundWorker));
snprintf(worker.bgw_name, BGW_MAXLEN, "background_worker");
worker.bgw_flags = BGWORKER_SHMEM_ACCESS | 
BGWORKER_BACKEND_DATABASE_CONNECTION;
worker.bgw_start_time = BgWorkerStart_RecoveryFinished;
worker.bgw_main = notify_main;
worker.bgw_restart_time = 10;
worker.bgw_main_arg = (Datum) 0;
worker.bgw_notify_pid = 0;
RegisterBackgroundWorker();

prev_log_hook = emit_log_hook;
emit_log_hook = store_notification;
}

void
_PG_fini(void)
{
emit_log_hook = prev_log_hook;
}

[GENERAL] zero length string to zero

[Shadi Mal]

Hi,
 I get zero length string in my result but I want to have zero value
instead.
what can I do?
my query is:
SELECT unreadmandatory.id,
 Count(unreadmandatory.course) AS nbrofmandatoryleft
   FROM unreadmandatory
  GROUP BY unreadmandatory.id

[GENERAL] disable ipv6?

[Jonathan Vanasco]

I'm running postgresql on ubuntu.  the 9.4 branch from postgresql.org

I think the only way to disable ipv6 is to edit postgresql.conf and explicitly 
state localhost in ipv4 as follows

- listen_addresses = 'localhost'
+ listen_addresses = '127.0.0.1'

can anyone confirm?




-- 
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] Update field to a column from another table

[David G. Johnston]

On Thursday, April 21, 2016, drum.lu...@gmail.com 
wrote:

> So when I run:
>
> UPDATE ja_jobs t2
>> SET time_job = t1.time_job
>> FROM junk.ja_test t1
>> WHERE t2.id = t1.id
>> AND t2.time_job IS DISTINCT FROM t1.time_job;
>
>
> I get:
>
> UPDATE 2202
>
> So I check the data by doing:
>
> select * FROM public.ja_jobs WHERE id = 14574527
>
>
> And the "time_job" field is null
>
>
Providing bits and pieces, without any data, is not going to get us
anywhere.

Create a self-contained test case the exhibits the problem.

David J.

Re: [GENERAL] Update field to a column from another table

[drum.lu...@gmail.com]

So when I run:

UPDATE ja_jobs t2
> SET time_job = t1.time_job
> FROM junk.ja_test t1
> WHERE t2.id = t1.id
> AND t2.time_job IS DISTINCT FROM t1.time_job;


I get:

UPDATE 2202

So I check the data by doing:

select * FROM public.ja_jobs WHERE id = 14574527


And the "time_job" field is null

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[John W Higgins]

On Thu, Apr 21, 2016 at 9:55 AM, Melvin Davidson 
wrote:

> Please, just ONE LOGICAL VALID argument, not speculation. Otherwise, stop
> with the nay saying.



I think you should look seriously at the suggestion offered of using an
event trigger to get what you desire here. I think the most logical
argument is that there is no need to do anything if a solution is available
on the table right now. Whether or not you agree with someone's fear of the
side effects of a larger solution - if you can use a tool that is already
available you should.

You are also more than happy to produce any patch that you would like to
offer up for inclusion. I completely appreciate that for any reason you may
not be able to offer up such a patch - but on the other hand - you cannot
demand that someone create the patch for you if they do not desire.

John

Re: [GENERAL] Initdb --data-checksums by default

[Vick Khera]

On Thu, Apr 21, 2016 at 9:00 AM, Alex Ignatov 
wrote:

> Ms Windows doesnt have ZFS support. AIX also doesnt. Z/OS also.  Any other
> commercial Linux distros don't have ZFS support. Yes you can compile it and
> use on production but...
> But PG runs on the above OS, but have check sum off by default. Thats the
> deal. And it is not related to ZFS existence or any other FS with checksums
> in any way. The question is only in performance hit when you turn it on
> and  now I am in the process of testing it...
>

I don't care about those platforms, so changing the default is just making
more work for me. :)

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Jan de Visser]

On Thursday, April 21, 2016 12:55:00 PM EDT Melvin Davidson wrote:
> WHY am I being vilified for making a simple request? How is it that
> developers proceed with other enhancements, yet so much negative attention
> is being given to my request because of unjustified fear that something bad
> will happen?

The open source development model is "scratch your itch". Stuff gets developed 
because people have problems and solve them. Apparently nobody has a 
sufficiently large itch to both scratch it and submit the result to the 
project.

The main difference between a project like this and a commercial product is 
that here there are no product managers defining roadmaps and writing 
requirements, but people bring solutions to problems *they* face or find 
interesting. So, if this is a thing you really care about: do a git checkout 
and start hacking. "Patches welcome".

And you're not being vilified. Your communication style is a tad, um, 
abrasive, and sometimes hard to deal with.



-- 
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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

On Thu, Apr 21, 2016 at 11:59 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Thu, Apr 21, 2016 at 8:18 AM, Melvin Davidson 
> wrote:
>
>> On Thu, Apr 21, 2016 at 11:08 AM, Adrian Klaver <
>> adrian.kla...@aklaver.com> wrote:
>>
>>> On 04/21/2016 07:53 AM, Melvin Davidson wrote:
>>>
>>>
 "Whether that is worthy or not is the point of your request and really
 depends on more input."
 Correct. And that is what I am looking for. Stating obscure corner cases
 does not rule out the need for an enhancement. If it did, there would be
 no point in any enhancement.
 As of yet, other than this will not work for certain cases, I have not
 heard any argument where this would cause harm to the PostgreSQL
 database (performance or security concern)
 or that this will take any great effort to implement, as I have already
 disproved that in a previous update.

>>>
>>> Making OIDs a default column on user tables was probably not a great
>>> effort either. Easy and all user tables got a built in PK, until folks
>>> started pushing more data into their database and the OID counter wrapped
>>> which had consequences for both user and system tables. Just saying I would
>>> want to hear more from the folks that deal with the internals.
>>>
>>>
>> And your point is? Adding an nullable column with a default of now() to a
>> system catalog has no impact whatsoever on OID's.
>> Please state a relevant  case how this negatively impacts anything.
>> ​
>>
>
> ​Y​
> our grasp of analogy
> ​ could use some work...
>
> That was a long winded way of saying that there is this thing called
> "unintended consequences".​
>
>
> ​https://en.wikipedia.org/wiki/Unintended_consequences
>
> Fear of both "unexpected drawbacks" and "perverse ​results" exist here.
>
> David J.
>
>
"Fear of both "unexpected drawbacks" and "perverse ​results" exist here."

And so far, NO ONE has shown any proof that this enhancement could possibly
cause ANY negative result.
All that has been presented so far are corner cases where this "might" not
be useful.
If the PostgreSQL developers are really worried about unexpected drawbacks,
then, based on that,  ALL future development should stop immediately.
This is total insanity! I am asking for a simple, safe enhancement that
would add what compatibility with what is already in other databases, yet
everyone seems to be terrified about it.
We have already modified system catalogs previously with no ill effect.

So please, someone present a logical explanation of why this should not be
done, or how it will negatively impact the PostgreSQL project.
If you cannot do so, then start thinking positively.

Previous to yesterday, nowhere on the PostgreSQL site was it stated WHERE
to present enhancement requests.
Now that it has been verified this is the correct list, There still exists
no formal requirements for presenting an enhancement request.
WHY am I being vilified for making a simple request? How is it that
developers proceed with other enhancements, yet so much negative attention
is being given to my request because of unjustified fear that something bad
will happen?

Please, just ONE LOGICAL VALID argument, not speculation. Otherwise, stop
with the nay saying.

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] Columnar store as default for PostgreSQL 10?

[Bráulio Bhavamitra]

On Thu, Apr 21, 2016 at 1:39 PM Geoff Winkless  wrote:

> On 21 April 2016 at 17:08, David G. Johnston 
> wrote:
> > I have little experience (and nothing practical) with columnar store but
> at
> > a high level I don't see the point.  I would hope that anyone interested
> in
> > working on a columnar store database would pick an existing one to
> improve
> > rather than converting a very successful row store database into one.
> And I
> > don't immediately understand how a dual setup would even be viable - it
> > seems like you'd have to re-write so much
> > of the code the only thing left would be the SQL parser.
>
> To be fair, I'd say that this "only thing" would be pretty huge. The
> cost of changing databases is often prohibitive (or nearly so) because
> the parser isn't _quite_ the same, and if the sort of gains that are
> bandied about could really be achieved just by choosing columnar
> storage for certain tables without having to rewrite large chunks of
> code that would be a very big win.
>
> I certainly agree that changing the store to columnar-only makes
> little sense though, because it would alienate a lot (I would suggest
> the majority) of users whose data fits far better into a row model.
>
> FWIW, looking at the cstore_fdw extension did get me quite excited
> (because I have an inkling that quite a lot of our queries might
> benefit from such a feature) until I saw that DELETEs aren't possible,
> which would invalidate most of the wins for us because of the
> subsequent massive cost of modifying data.
>
> There's also an interesting document from the monet_db guys about how
> the wins to be gained just by using cstore_fdw (rather than moving to
> a native column-store) aren't as high as you would hope. I have a
> feeling that would remain the case even if the store were integrated.
>
>
> https://www.monetdb.org/content/citusdb-postgresql-column-store-vs-monetdb-tpc-h-shootout
> " the margin by which MonetDB outperforms cstore_ftw shows that only
> switching storage models alone is probably not enough"
>
I think the gains are really high as with big data caching is usually not
really possible.
But of course cstore_fdw should perform better when caching is feasible.


>
> Geoff
> (Disclaimer: I've no connection to MonetDB in any way)
>

Re: [GENERAL] Columnar store as default for PostgreSQL 10?

[Geoff Winkless]

On 21 April 2016 at 17:08, David G. Johnston  wrote:
> I have little experience (and nothing practical) with columnar store but at
> a high level I don't see the point.  I would hope that anyone interested in
> working on a columnar store database would pick an existing one to improve
> rather than converting a very successful row store database into one.  And I
> don't immediately understand how a dual setup would even be viable - it
> seems like you'd have to re-write so much
> of the code the only thing left would be the SQL parser.

To be fair, I'd say that this "only thing" would be pretty huge. The
cost of changing databases is often prohibitive (or nearly so) because
the parser isn't _quite_ the same, and if the sort of gains that are
bandied about could really be achieved just by choosing columnar
storage for certain tables without having to rewrite large chunks of
code that would be a very big win.

I certainly agree that changing the store to columnar-only makes
little sense though, because it would alienate a lot (I would suggest
the majority) of users whose data fits far better into a row model.

FWIW, looking at the cstore_fdw extension did get me quite excited
(because I have an inkling that quite a lot of our queries might
benefit from such a feature) until I saw that DELETEs aren't possible,
which would invalidate most of the wins for us because of the
subsequent massive cost of modifying data.

There's also an interesting document from the monet_db guys about how
the wins to be gained just by using cstore_fdw (rather than moving to
a native column-store) aren't as high as you would hope. I have a
feeling that would remain the case even if the store were integrated.

https://www.monetdb.org/content/citusdb-postgresql-column-store-vs-monetdb-tpc-h-shootout
" the margin by which MonetDB outperforms cstore_ftw shows that only
switching storage models alone is probably not enough"

Geoff
(Disclaimer: I've no connection to MonetDB in any way)


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] On the building of a PostgreSQL cluster

[Srihari Sriraman]

Hey guys,

I recently gave a talk on building a PostgreSQL cluster, giving accounts of
a few stories of how things went wrong.

Here's the talk: https://www.youtube.com/watch?v=OzoyRv_7fEk
And here are the slides:
https://speakerdeck.com/srihari/on-the-building-of-a-postgres-cluster

I'd love to know what you guys think :)

-- 
Regards,
Srihari Sriraman -- ⌀ -- nilenso.com

Re: [GENERAL] Update field to a column from another table

[David G. Johnston]

Please don't top-post.


> > -Original Message-
> > From: pgsql-general-ow...@postgresql.org [mailto:
> pgsql-general-ow...@postgresql.org] On Behalf Of
> > drum.lu...@gmail.com
> > Sent: Donnerstag, 21. April 2016 07:10
> > To: Postgres General 
> > Subject: [GENERAL] Update field to a column from another table
> >
> > I've got two tables:
> >
> > - ja_jobs
> > - junk.ja_jobs_23856
> >
> > I need to update the null column ja_jobs.time_job with the data from the
> table  junk.ja_jobs_23856
> >
> > So I'm doing:
> >
> >
> >   UPDATE public.ja_jobs AS b
> >   SET   time_job = a.time_job
> >   FROM junk.ja_jobs_23856 AS a
> >   WHERE a.id  =
> ​b.id​
>
> >   AND a.clientid = b.clientid;
> >
> >
> > But it's now working... I'm using PostgreSQL 9.2
> >
> > Do you guys have an idea why?
> >
>

​Define "not working".

The query itself looks fine.

The likely cause is there are no records that share both an "id" and a
"clientid" value.


> ​
> ​
> On Wed, Apr 20, 2016 at 10:53 PM, Charles Clavadetscher <
> clavadetsc...@swisspug.org> wrote:
>
>> Hi
>>
>> This could work:
>>
>> UPDATE public.ja_jobs
>> SET time_job = a.tj
>> FROM
>> (
>>   SELECT id AS rid,
>>  clientid AS cid,
>>  time_job AS tj
>>   FROM junk.ja_jobs_23856
>> ) AS a
>> WHERE a.rid = id
>> AND a.cid = clientid;
>>
>> In the subselect a you need to rename the column names to avoid ambiguity.
>>
>
This shouldn't make any different.  The original query prefixed column
names with their source table so no ambiguity was present.

​David J.
​

Re: [GENERAL] Columnar store as default for PostgreSQL 10?

[David G. Johnston]

On Thu, Apr 21, 2016 at 3:08 AM, Bráulio Bhavamitra 
wrote:

> Hi all,
>
> I'm finally having performance issues with PostgreSQL when doing big
> analytics queries over almost the entire database of more than 100gb of
> data.
>
> And what I keep reading all over the web is many databases switching to
> columnar store (RedShift, Cassandra, cstore_fdw, etc) and having great
> performance on queries in general and giant boosts with big analytics
> queries.
>
> I wonder if there is any plans to move postgresql entirely to a columnar
> store (or at least make it an option), maybe for version 10?
>
> The current extensions are rather limited (types support for example) and
> require quite some configuration and data migration to work, besides they
> don't work in services like AWS RDS.
>

​I have little experience (and nothing practical) with columnar store but
at a high level I don't see the point.  I would hope that anyone interested
in working on a columnar store database would pick an existing one to
improve rather than converting a very successful row store database into
one.  And I don't immediately understand how a dual setup would even be
viable - it seems like you'd have to re-write so much
​of the code the only thing left would be the SQL parser.

​
​David J.
​

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[David G. Johnston]

On Thu, Apr 21, 2016 at 8:18 AM, Melvin Davidson 
wrote:

> On Thu, Apr 21, 2016 at 11:08 AM, Adrian Klaver  > wrote:
>
>> On 04/21/2016 07:53 AM, Melvin Davidson wrote:
>>
>>
>>> "Whether that is worthy or not is the point of your request and really
>>> depends on more input."
>>> Correct. And that is what I am looking for. Stating obscure corner cases
>>> does not rule out the need for an enhancement. If it did, there would be
>>> no point in any enhancement.
>>> As of yet, other than this will not work for certain cases, I have not
>>> heard any argument where this would cause harm to the PostgreSQL
>>> database (performance or security concern)
>>> or that this will take any great effort to implement, as I have already
>>> disproved that in a previous update.
>>>
>>
>> Making OIDs a default column on user tables was probably not a great
>> effort either. Easy and all user tables got a built in PK, until folks
>> started pushing more data into their database and the OID counter wrapped
>> which had consequences for both user and system tables. Just saying I would
>> want to hear more from the folks that deal with the internals.
>>
>>
> And your point is? Adding an nullable column with a default of now() to a
> system catalog has no impact whatsoever on OID's.
> Please state a relevant  case how this negatively impacts anything.
> ​
>

​Y​
our grasp of analogy
​ could use some work...

That was a long winded way of saying that there is this thing called
"unintended consequences".​


​https://en.wikipedia.org/wiki/Unintended_consequences

Fear of both "unexpected drawbacks" and "perverse ​results" exist here.

David J.

Re: [GENERAL] setting time zone in a function

[Tom Lane]

Steve Rogerson  writes:
> I wonder what counts as a valid time zone

http://www.postgresql.org/docs/9.5/static/datatype-datetime.html#DATATYPE-TIMEZONES

> ... I wasn't expecting this:

> # set timezone = '==2.77';
> SET
> # select now();
>   now
> ---
>  2016-04-18 09:40:52.089375-77
> (1 row)

Postgres is *very* lax about what is a valid timezone abbreviation in
the POSIX notation, mainly because the underlying Olson code is too.
I think it's taking that as '==' being the standard zone abbreviation
and '.' being the DST zone abbreviation.

If you wanted to restrict input to be the Olson-style zone names,
you could do some kind of precheck, maybe insist on only letters/
slashes/underscores.

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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

On Thu, Apr 21, 2016 at 11:08 AM, Adrian Klaver 
wrote:

> On 04/21/2016 07:53 AM, Melvin Davidson wrote:
>
>
>> "Whether that is worthy or not is the point of your request and really
>> depends on more input."
>> Correct. And that is what I am looking for. Stating obscure corner cases
>> does not rule out the need for an enhancement. If it did, there would be
>> no point in any enhancement.
>> As of yet, other than this will not work for certain cases, I have not
>> heard any argument where this would cause harm to the PostgreSQL
>> database (performance or security concern)
>> or that this will take any great effort to implement, as I have already
>> disproved that in a previous update.
>>
>
> Making OIDs a default column on user tables was probably not a great
> effort either. Easy and all user tables got a built in PK, until folks
> started pushing more data into their database and the OID counter wrapped
> which had consequences for both user and system tables. Just saying I would
> want to hear more from the folks that deal with the internals.
>
>
>
>> --
>> *Melvin Davidson*
>> I reserve the right to fantasize.  Whether or not you
>> wish to share my fantasy is entirely up to you.
>>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

And your point is? Adding an nullable column with a default of now() to a
system catalog has no impact whatsoever on OID's.
Please state a relevant  case how this negatively impacts anything.

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] setting time zone in a function

[Steve Rogerson]

On 21/04/16 14:47, Tom Lane wrote:
> Steve Rogerson  writes:
>> I want the time zone if a function  a bit like ...
>> CREATE OR REPLACE FUNCTION
>>short_name (timestamp with time zone, varchar) RETURNS varchar  AS $$
>> DECLARE
>> ...
>> BEGIN
>> SET LOCAL TIME ZONE $2;
> 
> Nope, that won't work: in general you can't put parameters into
> utility commands.  Use set_config():
>

That works. Thanks.

>   PERFORM set_config('timezone', $2, true);
> 
> Also, I think "SET LOCAL" has transaction duration, not function duration,
> so you're going to have to work harder than this if you want the setting
> to be local to this function.  SET LOCAL/set_config(true) inside an
> exception block might work --- and you may well want an exception block
> anyway, to trap bad timezone names.  Or you could explicitly save and
> restore the previous setting, which is more code but might be faster
> than an exception block.



I wonder what counts as a valid time zone, I wasn't expecting this:

# set timezone = '==2.77';
SET
# select now();
  now
---
 2016-04-18 09:40:52.089375-77
(1 row)

In my context I'm expecting an Olson type designation, "Europe/Madrid", I
guess that's hard to check for. I *think* I can live with the consequences, or
rather let a higher level deal with the problem. I would consider the above
time zone to be invalid.


Steve




-- 
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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Adrian Klaver]

On 04/21/2016 07:53 AM, Melvin Davidson wrote:



"Whether that is worthy or not is the point of your request and really
depends on more input."
Correct. And that is what I am looking for. Stating obscure corner cases
does not rule out the need for an enhancement. If it did, there would be
no point in any enhancement.
As of yet, other than this will not work for certain cases, I have not
heard any argument where this would cause harm to the PostgreSQL
database (performance or security concern)
or that this will take any great effort to implement, as I have already
disproved that in a previous update.


Making OIDs a default column on user tables was probably not a great 
effort either. Easy and all user tables got a built in PK, until folks 
started pushing more data into their database and the OID counter 
wrapped which had consequences for both user and system tables. Just 
saying I would want to hear more from the folks that deal with the 
internals.




--
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.



--
Adrian Klaver
adrian.kla...@aklaver.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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

On Thu, Apr 21, 2016 at 10:44 AM, Adrian Klaver 
wrote:

> On 04/21/2016 07:30 AM, Melvin Davidson wrote:
>
>>
>>
>>
>
>>
>> "Just one example of why that assertion does not hold:"
>>
>> I fail to see your point
>>
>> "That is easy. Compare dumps of the current schema against the
>> official schema."
>>
>> So your solution is to do a dump and then grep for anomalies? How is
>> that faster than just querying for recently created objects, or objects
>> created at odd days/hours (weekends/early moring)?
>>
>> You seem to be spending all of your time finding exemptions rather than
>> understanding the benefit. So what is your point? That it is not
>> worthwhile because there are a few cases where it might not work?
>>
>
> The point is that simple is simple, it is dealing with the
> exceptions/corner cases/etc that things get complex. While an individual
> user may want only simple, the developers have to think about the user
> community as a whole and that is where the complexity comes in. Whether
> that is worthy or not is the point of your request and really depends on
> more input.
>
>
>> --
>> *Melvin Davidson*
>> I reserve the right to fantasize.  Whether or not you
>> wish to share my fantasy is entirely up to you.
>>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

"Whether that is worthy or not is the point of your request and really
depends on more input."
Correct. And that is what I am looking for. Stating obscure corner cases
does not rule out the need for an enhancement. If it did, there would be no
point in any enhancement.
As of yet, other than this will not work for certain cases, I have not
heard any argument where this would cause harm to the PostgreSQL database
(performance or security concern)
or that this will take any great effort to implement, as I have already
disproved that in a previous update.

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Adrian Klaver]

On 04/21/2016 07:30 AM, Melvin Davidson wrote:








"Just one example of why that assertion does not hold:"

I fail to see your point

"That is easy. Compare dumps of the current schema against the
official schema."

So your solution is to do a dump and then grep for anomalies? How is
that faster than just querying for recently created objects, or objects
created at odd days/hours (weekends/early moring)?

You seem to be spending all of your time finding exemptions rather than
understanding the benefit. So what is your point? That it is not
worthwhile because there are a few cases where it might not work?


The point is that simple is simple, it is dealing with the 
exceptions/corner cases/etc that things get complex. While an individual 
user may want only simple, the developers have to think about the user 
community as a whole and that is where the complexity comes in. Whether 
that is worthy or not is the point of your request and really depends on 
more input.




--
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.



--
Adrian Klaver
adrian.kla...@aklaver.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] error while installing auto_explain contrib module

[Adrian Klaver]

On 04/21/2016 07:13 AM, Sachin Kotwal wrote:



On Thu, Apr 21, 2016 at 7:20 PM, Adrian Klaver
> wrote:

On 04/21/2016 02:23 AM, Sachin Kotwal wrote:

Hi Tom,

Thanks for reply.

On Tue, Apr 19, 2016 at 7:40 PM, Tom Lane 
>> wrote:

 Sachin Kotwal  >> writes:
 > On Tue, Apr 19, 2016 at 7:02 PM, Adrian Klaver

>>
 > wrote:
 >> Did you install the 9.3.11 server from source also?

 > Yes. I have clone git repository and checkout for  pg-9.3.11

 The reason for that question is that the most obvious
explanation
 for this
 failure is that the auto_explain build is seeing a
different value for
 PG_USE_INLINE than the main server build did.


Ok. But I am not getting getting why auto_explain is doing that.
All pg_config parameters have correct value as per my installation
posted in last mail.


Do you have a Postgres instance installed that did not come from the
Git clone?


Currently I do not have Postgres installation from other than Git but i
will try that soon.

I did same Postgres version installation of  on CentOS 6 , It is working
fine.


You did that as source install from the Git repo or via a package?



I think it is problem with OS X. On OS X contrib tools unable to find
correct installation paths.
I feel we need to fix them.


I do not use OS X, so I will not be of much help there.






Is it correct behaviour of auto_explain or it is bug ?

 So probably your include
 path is picking up a pg_config.h that does not match the
postgres
 executable the link is happening against.

  regards, tom lane


If pg_config showing following as INCLUDEDIR path

INCLUDEDIR = /Users/sachin/pg_git_install/9.3.11/include


How it can take pg_config.h from different include path?

Can you tell me where i should look in auto_explain to fix this?


--

Thanks and Regards,
Sachin Kotwal



--
Adrian Klaver
adrian.kla...@aklaver.com 




--

Thanks and Regards,
Sachin Kotwal



--
Adrian Klaver
adrian.kla...@aklaver.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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

On Thu, Apr 21, 2016 at 10:08 AM, Karsten Hilbert 
wrote:

> On Thu, Apr 21, 2016 at 09:40:18AM -0400, Melvin Davidson wrote:
>
> > "and what about user objects added to a database which is
> > then used as a template for creating another DB ?"
> >
> > This existence of objects that are part of the default schema is NOT a
> > problem. Developers and users should never have access to a template.
>
> Just one example of why that assertion does not hold:
>
> GNUmed stores medical records. There's no allowance for
> loosing data. One measure it takes to protect data is to
> execute (roughly) the following sequence when a database
> schema upgrade is needed (currently at major release 21
> thereof). Say, going from v20 to v21:
>
> - create database 'gnumed_v21' template 'gnumed_v20'
> - from this point on gnumed_v20 is NOT TOUCHED anymore
> - at this point gnumed_v21 is identical to gnumed_v20 as far as GNUmed is
> concerned
> - apply - to gnumed_v21 - those SQL fixups scripts intended to
>   bring v20 up to the very latest minor release of v20
> - apply - to gnumed_v21 - the v20.latest->v21 upgrade SQL scripts
> - apply - to gnumed_v21 - the SQL fixup scripts intended to
>   bring v21 up to the very latest minor release of v21
>
> Whatever goes wrong after having cloned gnumed_v20 into
> gnumed_v21 doesn't matter to the user because they can
> _always_ go back to using the gnumed_v20 database until a
> future upgrade run succeeds at which point they can switch
> over.
>
> Of course, this can also be done via dump v20 / restore into
> v21 but that's slightly more fragile (more things can go
> wrong).
>
> > The point is to be able to track down rogue objects created
> > by developers and users
>
> That is easy. Compare dumps of the current schema against the
> official schema.
>
> In fact, GNUmed does so. The upgrade does not even start if
> the template schema does not pass an md5 comparison and it
> does not consider success unless the upgraded schema passes
> another (target) md5 comparison.
>
> Furthermore, the client refuses to connect to a given
> database if it cannot verify that database's schema via
> expected md5 thereof.
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

"Just one example of why that assertion does not hold:"

I fail to see your point

"That is easy. Compare dumps of the current schema against the
official schema."

So your solution is to do a dump and then grep for anomalies? How is that
faster than just querying for recently created objects, or objects created
at odd days/hours (weekends/early moring)?

You seem to be spending all of your time finding exemptions rather than
understanding the benefit. So what is your point? That it is not worthwhile
because there are a few cases where it might not work?

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] error while installing auto_explain contrib module

[Sachin Kotwal]

On Thu, Apr 21, 2016 at 7:20 PM, Adrian Klaver 
wrote:

> On 04/21/2016 02:23 AM, Sachin Kotwal wrote:
>
>> Hi Tom,
>>
>> Thanks for reply.
>>
>> On Tue, Apr 19, 2016 at 7:40 PM, Tom Lane > > wrote:
>>
>> Sachin Kotwal >
>> writes:
>> > On Tue, Apr 19, 2016 at 7:02 PM, Adrian Klaver <
>> adrian.kla...@aklaver.com >
>> > wrote:
>> >> Did you install the 9.3.11 server from source also?
>>
>> > Yes. I have clone git repository and checkout for  pg-9.3.11
>>
>> The reason for that question is that the most obvious explanation
>> for this
>> failure is that the auto_explain build is seeing a different value for
>> PG_USE_INLINE than the main server build did.
>>
>>
>> Ok. But I am not getting getting why auto_explain is doing that.
>> All pg_config parameters have correct value as per my installation
>> posted in last mail.
>>
>
> Do you have a Postgres instance installed that did not come from the Git
> clone?


Currently I do not have Postgres installation from other than Git but i
will try that soon.

I did same Postgres version installation of  on CentOS 6 , It is working
fine.

I think it is problem with OS X. On OS X contrib tools unable to find
correct installation paths.
I feel we need to fix them.



>> Is it correct behaviour of auto_explain or it is bug ?
>>
>> So probably your include
>> path is picking up a pg_config.h that does not match the postgres
>> executable the link is happening against.
>>
>>  regards, tom lane
>>
>>
>> If pg_config showing following as INCLUDEDIR path
>>
>> INCLUDEDIR = /Users/sachin/pg_git_install/9.3.11/include
>>
>>
>> How it can take pg_config.h from different include path?
>>
>> Can you tell me where i should look in auto_explain to fix this?
>>
>>
>> --
>>
>> Thanks and Regards,
>> Sachin Kotwal
>>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>



-- 

Thanks and Regards,
Sachin Kotwal

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Karsten Hilbert]

On Thu, Apr 21, 2016 at 09:40:18AM -0400, Melvin Davidson wrote:

> "and what about user objects added to a database which is
> then used as a template for creating another DB ?"
> 
> This existence of objects that are part of the default schema is NOT a
> problem. Developers and users should never have access to a template.

Just one example of why that assertion does not hold:

GNUmed stores medical records. There's no allowance for
loosing data. One measure it takes to protect data is to
execute (roughly) the following sequence when a database
schema upgrade is needed (currently at major release 21
thereof). Say, going from v20 to v21:

- create database 'gnumed_v21' template 'gnumed_v20'
- from this point on gnumed_v20 is NOT TOUCHED anymore
- at this point gnumed_v21 is identical to gnumed_v20 as far as GNUmed is 
concerned
- apply - to gnumed_v21 - those SQL fixups scripts intended to
  bring v20 up to the very latest minor release of v20
- apply - to gnumed_v21 - the v20.latest->v21 upgrade SQL scripts
- apply - to gnumed_v21 - the SQL fixup scripts intended to
  bring v21 up to the very latest minor release of v21

Whatever goes wrong after having cloned gnumed_v20 into
gnumed_v21 doesn't matter to the user because they can
_always_ go back to using the gnumed_v20 database until a
future upgrade run succeeds at which point they can switch
over.

Of course, this can also be done via dump v20 / restore into
v21 but that's slightly more fragile (more things can go
wrong).

> The point is to be able to track down rogue objects created 
> by developers and users

That is easy. Compare dumps of the current schema against the
official schema.

In fact, GNUmed does so. The upgrade does not even start if
the template schema does not pass an md5 comparison and it
does not consider success unless the upgraded schema passes
another (target) md5 comparison.

Furthermore, the client refuses to connect to a given
database if it cannot verify that database's schema via
expected md5 thereof.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
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] Invalid data read from synchronously replicated hot standby

[Adrian Klaver]

On 04/21/2016 01:05 AM, martin.kamp.jen...@schneider-electric.com wrote:

Hi,

We are getting invalid data when reading from a synchronously replicated
hot standby node in a 2-node setup. To better understand the situation,
we have created a document that provides an overview. We are hoping that
someone might be able to confirm whether or not the setup makes sense,
i.e., whether we are using PostgreSQL correctly and experiencing a bug,
or if we are using PostgreSQL incorrectly.

Link to document that contains a step-by-step description of the
situation:
https://docs.google.com/document/d/1MuX8rq1gKw_WZ-HVflqxFslvXNTRGKa77A4NHto4ue0/edit?usp=sharing


If the setup is sane (and expected to work), we will work on setting up
a minimal reproduce that avoids our complete system. We are thinking
that a scripted Ansible/Vagrant setup makes sense.


Questions:

What is wal_level set to?

Why on Node A do you have in recovery.conf?:
primary_conninfo = 'host='

What exactly are you trying to do?

Looks to me you are trying to have multi-master, is that the case?



Best regards,
Martin



--
Adrian Klaver
adrian.kla...@aklaver.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] Is it possible to call Postgres directly?

[Tom Lane]

 writes:
> So the question is: Can a C program link to the Postgres DLL and call SPI
> directly, rather than through a language function?

No, there is no provision for non-server usage of the code.  If that's
what you're after you might be happier with SQLite or something similar.

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] error while installing auto_explain contrib module

[Adrian Klaver]

On 04/21/2016 02:23 AM, Sachin Kotwal wrote:

Hi Tom,

Thanks for reply.

On Tue, Apr 19, 2016 at 7:40 PM, Tom Lane > wrote:

Sachin Kotwal > writes:
> On Tue, Apr 19, 2016 at 7:02 PM, Adrian Klaver >
> wrote:
>> Did you install the 9.3.11 server from source also?

> Yes. I have clone git repository and checkout for  pg-9.3.11

The reason for that question is that the most obvious explanation
for this
failure is that the auto_explain build is seeing a different value for
PG_USE_INLINE than the main server build did.


Ok. But I am not getting getting why auto_explain is doing that.
All pg_config parameters have correct value as per my installation
posted in last mail.


Do you have a Postgres instance installed that did not come from the Git 
clone?




Is it correct behaviour of auto_explain or it is bug ?

So probably your include
path is picking up a pg_config.h that does not match the postgres
executable the link is happening against.

 regards, tom lane


If pg_config showing following as INCLUDEDIR path

INCLUDEDIR = /Users/sachin/pg_git_install/9.3.11/include


How it can take pg_config.h from different include path?

Can you tell me where i should look in auto_explain to fix this?


--

Thanks and Regards,
Sachin Kotwal



--
Adrian Klaver
adrian.kla...@aklaver.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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

"and what about user objects added to a database which is
then used as a template for creating another DB ?"

This existence of objects that are part of the default schema is NOT a
problem. Developers and users should never have access to a template. The
point is to be able to track down rogue objects created  by developers and
users and at the same time add the same functionality as already is in
Oracle and SQL Server. What would be your solution?


*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] setting time zone in a function

[Tom Lane]

Steve Rogerson  writes:
> I want the time zone if a function  a bit like ...
> CREATE OR REPLACE FUNCTION
>short_name (timestamp with time zone, varchar) RETURNS varchar  AS $$
> DECLARE
> ...
> BEGIN
> SET LOCAL TIME ZONE $2;

Nope, that won't work: in general you can't put parameters into
utility commands.  Use set_config():

PERFORM set_config('timezone', $2, true);

Also, I think "SET LOCAL" has transaction duration, not function duration,
so you're going to have to work harder than this if you want the setting
to be local to this function.  SET LOCAL/set_config(true) inside an
exception block might work --- and you may well want an exception block
anyway, to trap bad timezone names.  Or you could explicitly save and
restore the previous setting, which is more code but might be faster
than an exception block.

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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

"Speaking blindly here but given that we now have event triggers I'm even
more inclined to simply tell people to setup user-space tables and event
triggers to do whatever they want.  Is there any reason that combination
cannot solve the problems being brought up?  I get the desirability of
having something in-core but this seems like a perfect problem for which
PGXN should be the solution."

Wekk, yes and no. To use event triggers requires that a user first create
their own audit table, then create a function to process the event, and
finally create the event trigger. That works fine for the single database
situation, but when you have hundreds of servers and databases to monitor
(as I did), it makes the implementation a bit more daunting. Whereas having
relcreatedat would mean "no muss, no fuss". :)


-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] Initdb --data-checksums by default

[Alex Ignatov]

On 20.04.2016 23:28, Vick Khera wrote:


On Wed, Apr 20, 2016 at 3:43 AM, Alex Ignatov 
> wrote:


What do you think about defaulting --data-checksums in initdb?


I think that ZFS storing my database files already does this and can 
correct for it using replicated copies, so why do I need a second 
layer of checksums?


Ms Windows doesnt have ZFS support. AIX also doesnt. Z/OS also.  Any 
other commercial Linux distros don't have ZFS support. Yes you can 
compile it and use on production but...
But PG runs on the above OS, but have check sum off by default. Thats 
the deal. And it is not related to ZFS existence or any other FS with 
checksums in any way. The question is only in performance hit when you 
turn it on and  now I am in the process of testing it...


--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Melvin Davidson]

On Thu, Apr 21, 2016 at 3:11 AM, Karsten Hilbert 
wrote:

> On Wed, Apr 20, 2016 at 07:09:24PM -0400, Melvin Davidson wrote:
>
> > There is also the situation of tables with limitited use. EG:
> > history_mm, in which case it would facilitate dropping of tables that
> > are no longer needed after x amount of time.
>
> select * from pg_class where to_timestamp(substring(relname from
> 9), 'MM') CONDITION;
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>


"select * from pg_class where to_timestamp(substring(relname from 9),
'MM') CONDITION;"
Yes, that might possibly work, but history_MM was just an example
illustration. What if the table name did not have a date in it?
eg: persons_things_done,
Then you need the creation date of the table.

-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] Invalid data read from synchronously replicated hot standby

[Sameer Kumar]

On Thu, 21 Apr 2016 04:05 , 
wrote:

> Hi,
>
> We are getting invalid data when reading from a synchronously replicated
> hot standby node in a 2-node setup. To better understand the situation, we
> have created a document that provides an overview. We are hoping that
> someone might be able to confirm whether or not the setup makes sense,
> i.e., whether we are using PostgreSQL correctly and experiencing a bug, or
> if we are using PostgreSQL incorrectly.
>
> Link to document that contains a step-by-step description of the
> situation:
> https://docs.google.com/document/d/1MuX8rq1gKw_WZ-HVflqxFslvXNTRGKa77A4NHto4ue0/edit?usp=sharing
>
>
>
>
>
> If the setup is sane (and expected to work), we will work on setting up a
> minimal reproduce that avoids our complete system. We are thinking that a
> scripted Ansible/Vagrant setup makes sense.
>

I am not sure if it is because of that but you are on an old patch. Upgrade
to latest (I guess 9.1.21).

Once you have upgraded, re-create the stand by from scratch using a
basebackup and then see if the error is still there.


> Best regards,
> Martin
>
-- 
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533

T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com

Re: [GENERAL] Columnar store as default for PostgreSQL 10?

[Francisco Olarte]

Hi Bráulio:

On Thu, Apr 21, 2016 at 12:08 PM, Bráulio Bhavamitra
 wrote:
> And what I keep reading all over the web is many databases switching to
> columnar store (RedShift, Cassandra, cstore_fdw, etc) and having great
> performance on queries in general and giant boosts with big analytics
> queries.

And have you read anything about the drawbacks of columnar? They are
there, but writing about them does not makes the headlines.

> I wonder if there is any plans to move postgresql entirely to a columnar
> store (or at least make it an option), maybe for version 10?

An option may be good ( may, not sure because nothing is free. More
complex code, more bug surface, some time will be eaten managing the
extra complexity, less developer time available for each feature, ...
) , but IMHO a complete move would be bad. Columnar is not that good
for a lot of postgres usages. If columnar were the silver bullet
everybody would be doing it.

Francisco Olarte.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] setting time zone in a function

[Steve Rogerson]

I want the time zone if a function  a bit like ...

CREATE OR REPLACE FUNCTION
   short_name (timestamp with time zone, varchar) RETURNS varchar  AS $$
DECLARE
...
BEGIN
SET LOCAL TIME ZONE $2;
SELECT to_char($1, 'TZ')::varchar
...
END $$
LANGUAGE 'plpgsql' VOLATILE;


But as written is doesn't compile complaining about the "naked" $2. If I quote
the $2 it sets the time zone to $2 literally (I didn't know you could do that,
but that's another issue). Escaping the quotes either as \' or '' doesn't 
compile.

Help.


Steve


-- 
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] error while installing auto_explain contrib module

[Sachin Kotwal]

Hi Tom,

Thanks for reply.

On Tue, Apr 19, 2016 at 7:40 PM, Tom Lane  wrote:

> Sachin Kotwal  writes:
> > On Tue, Apr 19, 2016 at 7:02 PM, Adrian Klaver <
> adrian.kla...@aklaver.com>
> > wrote:
> >> Did you install the 9.3.11 server from source also?
>
> > Yes. I have clone git repository and checkout for  pg-9.3.11
>
> The reason for that question is that the most obvious explanation for this
> failure is that the auto_explain build is seeing a different value for
> PG_USE_INLINE than the main server build did.


Ok. But I am not getting getting why auto_explain is doing that.
All pg_config parameters have correct value as per my installation posted
in last mail.

Is it correct behaviour of auto_explain or it is bug ?


> So probably your include
> path is picking up a pg_config.h that does not match the postgres
> executable the link is happening against.
>
> regards, tom lane
>

If pg_config showing following as INCLUDEDIR path

INCLUDEDIR = /Users/sachin/pg_git_install/9.3.11/include


How it can take pg_config.h from different include path?
Can you tell me where i should look in auto_explain to fix this?


-- 

Thanks and Regards,
Sachin Kotwal

Re: [GENERAL] Is it possible to call Postgres directly?

[John R Pierce]

On 4/20/2016 10:59 PM, da...@andl.org wrote:

So the question is: Can a C program link to the Postgres DLL and call SPI
directly, rather than through a language function?

Is there a way to launch a Thrift server or a Web server and call SPI
directly?



no, those can only be called from the context of a function that was 
called from SQL as part of a query.


if you want to completely replace SQL as the query language, why don't 
you just provide your own Andl API, and have it run in the client 
context and execute SQL queries via the normal libpq style API ?


you could still use pl/andl for things like triggers and such but not 
for direct client queries.



--
john r pierce, recycling bits in santa cruz



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Invalid data read from synchronously replicated hot standby

[martin . kamp . jensen]

Hi,

We are getting invalid data when reading from a synchronously replicated 
hot standby node in a 2-node setup. To better understand the situation, we 
have created a document that provides an overview. We are hoping that 
someone might be able to confirm whether or not the setup makes sense, 
i.e., whether we are using PostgreSQL correctly and experiencing a bug, or 
if we are using PostgreSQL incorrectly.

Link to document that contains a step-by-step description of the 
situation: 
https://docs.google.com/document/d/1MuX8rq1gKw_WZ-HVflqxFslvXNTRGKa77A4NHto4ue0/edit?usp=sharing

If the setup is sane (and expected to work), we will work on setting up a 
minimal reproduce that avoids our complete system. We are thinking that a 
scripted Ansible/Vagrant setup makes sense.

Best regards,
Martin

Re: [GENERAL] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Karsten Hilbert]

On Wed, Apr 20, 2016 at 07:09:24PM -0400, Melvin Davidson wrote:

> There is also the situation of tables with limitited use. EG:
> history_mm, in which case it would facilitate dropping of tables that
> are no longer needed after x amount of time.

select * from pg_class where to_timestamp(substring(relname from 9), 
'MM') CONDITION;

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Karsten Hilbert]

On Wed, Apr 20, 2016 at 05:17:20PM -0500, Kevin Grittner wrote:

> if someone had been allowed to run ad hoc
> reports or data cleanup on a database it was a quick way to look
> for stray tables they may have generated to keep intermediate
> results or exceptions, so we could follow up on disposition of
> those tables.

Would

pg_dump -schema-only
sort
diff official-DDL.sql.sorted

do, too ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
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] Add relcreated (timestamp) column to pg_class catalog to record the time an object was created

[Karsten Hilbert]

On Wed, Apr 20, 2016 at 03:02:52PM -0700, Adrian Klaver wrote:

> No one is arguing that slapping a new column on pg_class is not easy, just
> that the implications of doing so requires a good deal of thought. The first
> thing that comes to my mind(also in threads on --hackers) is what is the
> creation time?:
> 
> The first time an object was ever created?
> 
> The time it was created in a new database during a
> dump-restore/pg_upgrade/replication?

... and what about user objects added to a database which is
then used as a template for creating another DB ?

- initial add time ?
- template-reuse time ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
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 PostgreSQL 9.2

[Karsten Hilbert]

On Wed, Apr 20, 2016 at 03:55:50PM -0700, Adrian Klaver wrote:

> >If I am following, this duplicates the information in
> >companies.client_code_increment, in that they both return the last
> >non-user code. Of course this assumes, as David mentioned, that the
> >client is not using a numeric code system. Then you are left trying
> >to figure whether a number is 'your' number or 'their' number?
> >
> >
> >The customer can add any value into users.code:
> >
> >code CHARACTER VARYING,
> >
> >
> >But he also can let it blank/null if he wants to.
> >That's when the trigger do its job.. Put a value (starting in 1000) in
> >that column.
> 
> Understood, but what happens if the customer has been using a code of:
> 
> ... 998, 999, 1000
> 
> They then left the code null on the next two items and your function stuck
> in 1001 and 1002. Then they figured out what they wanted to do with the
> codes on their end but wanted the items to have codes of 1002, 1001 for the
> items you coded 1001, 1002 respectively.
> 
> >
> >Of course that has to be unique, as nobody can use the same value of others.
> 
> Unique within a customer, which is what your code implied or unique across
> all customers?
> 
> >
> >
> >- I was hoping you cans could help me to start doing the function...
> 
> Well, I am with David on this, either the customer is totally in charge of
> the codes or you are. The thought of mixing systems gives me a headache.

How about _two_ columns (pseudo code)

.user_picked_code (can be null)
.assigned_code not null serial starts_with 1000

would that help any ?   .assigned_code would always be set
from a sequence but .user_picked_code would be _used_ (say,
via a view) IF NOT NULL.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
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] Is it possible to call Postgres directly?

[david]

> > I would like to be able to execute SQL queries by a direct call into
> > Postgres, without going through either (1) the language call handler
> > or (2) a 'wire' protocol.
> 
> What would you consider to be "directly"?  What advantage would you hope
to
> gain from a different API?

The aim is to execute Andl code at the top level, not inside SQL. So instead
of:

>>>SELECT * FROM AndlFunc(args);

I need

>>>AndlFunc(args)

> FWIW, it seems unlikely to me that we would consider anything much lower-
> level than SPI to be an officially-supported query interface.
> You could no doubt run a query by calling assorted backend functions
directly
> from a PL implementation, but it would be mostly on your own head whether
> that worked and kept working across releases.

No, SPI is quite low enough level for me. I really don't want or need to go
lower than that.

So the question is: Can a C program link to the Postgres DLL and call SPI
directly, rather than through a language function?

Is there a way to launch a Thrift server or a Web server and call SPI
directly?

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general