Hi
One of reasons to get PL/proxy into core is to make it available to Windows
users also.
The idea is to get to the situation
createlang plproxy mydb
If we can achieve this without putting plproxy into core then i would like
to hear how.
Asko
On Fri, Jul 25, 2008 at 2:19 AM, Tom Lane <[EMAIL
Hello Tom,
On Thu, Jul 24, 2008 at 10:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>> I am looking to take advantage of PostgreSQL extensible type system
>> and implement unsigned integer support.
>
> This has been proposed before, and foundered before
On Thu, Jul 24, 2008 at 12:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
>>> Another issue is the interaction with the planned column-level GRANT
>>> feature.
>
>> Although that is a feature we want, is a WIP one... do we stop patches
>> because it can co
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> I am looking to take advantage of PostgreSQL extensible type system
> and implement unsigned integer support.
This has been proposed before, and foundered before on the question
of implicit coercions. If you're willing to make all coercions *to*
unsi
Hello hackers,
I know the development community is in the middle of the July 2008
commit-fest, so I apologize if this design proposals are in
appropriate at this time.
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support. The data I am deali
On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> And it would be nice, if some well-maintained sample language (pl/sh or
>> even pl/dummy) which serves as a sample of latest ways to make use of
>> pl/function support in core pg code
Simon Riggs <[EMAIL PROTECTED]> wrote:
> * access to version number
> * simple mechanism for conditional execution
> * ability to set substitution variables from command execution
> * conditional execution whether superuser or not
Can we use pgScript for such flow controls?
http://pgscript.proje
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Simon's patch to split up --schema-only into two switches has broken
> this logic, but I'm inclined to just rip it out rather than trying
> to fix it. If the user says --disable-triggers, he should get
> trigger disable commands around the data part of the d
> Now, I get a different problem, this time with the following code
> intended to materialize paths on the fly and summarize down to a
> certain depth in a tree:
>
> CREATE TABLE tree(
> id INTEGER PRIMARY KEY,
> parent_id INTEGER REFERENCES tree(id)
> );
>
> INSERT INTO tree
> VALUES (1,
On Thu, Jul 24, 2008 at 01:55:37PM +0900, Tatsuo Ishii wrote:
> > Program received signal SIGSEGV, Segmentation fault.
>
> Thanks for the report. Here is the new patches from Yoshiyuki.
Thanks for the patch :)
Now, I get a different problem, this time with the following code
intended to material
Tom Lane wrote:
If the user says --disable-triggers, he should get
trigger disable commands around the data part of the dump, no matter
what he said or didn't say about schema dumping.
Right. They seem like orthogonal issues.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-
"Robert Haas" <[EMAIL PROTECTED]> writes:
> ISTM that if that if you're willing to admit, even with caveats, that
> PL/perl, PL/tcl, or PL/python doesn't "need" to be in core, then
> excluding anything else from core on the basis that it doesn't need to
> be there is silly.
You are merely setting
There's some fairly squirrely logic in pg_dump/pg_restore that tries to
detect whether it's doing a data-only operation, ie, no schema
information is to be dumped or restored. The reason it wants to
know this is to decide whether to enable the --disable-triggers
code. However, since --disable-tri
On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
>>> These are all excellent points but I think the real problem here is:
>>> There is nothing that requires pl/proxy to be in
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
>> These are all excellent points but I think the real problem here is:
>> There is nothing that requires pl/proxy to be in core.
> AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/pyth
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> - GiST already supports both scan directions in theory, but page split may
> change order between forward and backward scans (user-defined pageSplit
> doesn't
> preserve order of tuples). Holding of split until end of scan will produce
> unacceptabl
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
> On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
> > On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
> > > In the case of plproxy, I think an integrated solution is pronounced
> > > "SQL-MED", and likewise plproxy in its present
queries return the same row twice. A bitmap indexscan plan would mask
such an index bug ... but a plain indexscan won't.
Fuh. :(. Well. Will fix.
GiST:
- GiST already supports both scan directions in theory, but page split may
change order between forward and backward scans (user-defined pag
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Reviewers, please let me know if you find problems with the
> patches. If none, I would like to commit this weekend.
Given that everyone who has tested this has found a different way to
crash it, and that the frequency of crash reports shows no signs of
s
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> operations such as page splits. Do we need to change the planner to
>> assume that this only works nicely for btree?
> It seems to that direction (backward or forward) has meaning only for
> indexes with amcanorder = true. With amcanorder=false results
operations such as page splits. Do we need to change the planner to
assume that this only works nicely for btree?
It seems to that direction (backward or forward) has meaning only for indexes
with amcanorder = true. With amcanorder=false results will be occasionally for
any direction.
--
Te
The fine manual claims that the "base dn" part of an LDAP URL
is meaningful:
The server will bind to the distinguished name specified as base
dn using the user name supplied by the client. If prefix and
suffix is specified, it will be prepended and appended to the
u
On Thu, 2008-07-24 at 17:54 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
> NotDashEscaped: You need GnuPG to verify this message
>
>
> >> shared_buffers is in disk block size, typically 8K
>
> > The table the OP is looking at (table 17.2 in the 8.3 doc
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
>> shared_buffers is in disk block size, typically 8K
> The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> the ability to specify shared_buffers in KB or MB instead of
>
On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> > Code outside of core, is, in reality, less reviewed, less likely to work
> > well with recent PG versions, and more likely to cause problems. It's also
> > less likely to be found by people, l
Simon Riggs <[EMAIL PROTECTED]> writes:
> I would prefer it if you had a plan to introduce user definable
> parameters, similar to custom_variable_classes. Perhaps call this
> "custom_table_options". So when we load a table and it has an option we
> don't recognise we ignore it if it is one of the
I wrote:
> Really? Then GiST needs to be fixed too. Otherwise you risk having
> queries return the same row twice. A bitmap indexscan plan would mask
> such an index bug ... but a plain indexscan won't.
BTW, there's another issue I forgot about yesterday, which is that
the planner assumes that
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
>> Another issue is the interaction with the planned column-level GRANT
>> feature.
> Although that is a feature we want, is a WIP one... do we stop patches
> because it can conflict with a project we don't know will be applied
> soon?
Well, considerin
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> * There is a bigger race condition, which is that after a scan has
>> returned a tuple from a pending page, vacuum could move the index entry
>> into the main index structure, and then that same scan could return that
>> same index entry a second time.
On Thu, Jul 24, 2008 at 9:06 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I suspect this is not the root problem, but one solution to it.
Agreed. It is not the root problem. However, until DSM is fully
implemented and working, not having the ability to gather statistics
during long vacuums is pr
Sorry for the delay in the answer but i was busy with 2 projects and a talk...
On Sat, Jul 12, 2008 at 3:50 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think it's probably reasonable as long as we keep the implicitly
> granted rights as narrow as possible. INSERT on the parent table
> would norma
On Jul 24, 2008, at 11:11 AM, Zdenek Kotala wrote:
I performed review and I prepared own patch which contains only
probes without any issue. I suggest commit this patch because the
rest of patch is independent and it can be committed next commit
fest after rework.
I found following issue
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
> On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
> > In the case of plproxy, I think an integrated solution is pronounced
> > "SQL-MED", and likewise plproxy in its present form doesn't move us
> > toward that goal.
> I'm pretty sure that
On Tue, 2008-07-22 at 11:25 -0400, Tom Lane wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > And user can execute only pre-determines queries/functions on system2.
>
> If that were actually the case then the security issue wouldn't loom
> quite so large, but the dynamic_query example in the
On Mon, 2008-07-21 at 17:50 -0400, Jonah H. Harris wrote:
> Currently, one cannot perform a concurrent VACUUM and ANALYZE. This
> is a significant problem for tables which are not only large and have
> designated cost-delays, but which are also heavily inserted into and
> deleted from.
I suspect
* shiftList() holds an exclusive lock on metapage throughout its run,
which means that it's impossible for two of them to run concurrently.
So why bother with "concurrent deletion" detection?
Because metapage is locked immediately before shiftList call, while metapage is
unlocked another proces
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
>> Given the very short list of supported
>> reloptions right now, why would you imagine that there will ever
>> be such a thing as installation-local reloptions?
> There's a ton of ways to introduce insta
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
> In the case of plproxy, I think an integrated solution is pronounced
> "SQL-MED", and likewise plproxy in its present form doesn't move us
> toward that goal.
While pl/proxy can be tweaked into a way of achieving functionality of
SQL-MED ("SQL/M
I performed review and I prepared own patch which contains only probes without
any issue. I suggest commit this patch because the rest of patch is independent
and it can be committed next commit fest after rework.
I found following issues:
1) SLRU probes.
I think it is good to have probes the
On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I would prefer it if you had a plan to introduce user definable
> > parameters, similar to custom_variable_classes. Perhaps call this
> > "custom_table_options". So when we load a table and it has an o
Hi.
Sorry, very late reaction
I'm based on the environment of VC++2005 and MinGW by the reason for requiring
official
support. and since it does not have many resources, the environment of VC++2008 is
restricted.
Therefore, many suggestion can't be performed now:-(
- Original Mes
On Thu, 2008-07-24 at 19:09 +0900, ITAGAKI Takahiro wrote:
> CREATE TABLE LIKE is useful to create a new partition from a template
> table. We can use 3 options (INCLUDING DEFAULTS, CONSTRAINTS and INDEXES)
> to copy more parameters from the template, but there are still some
> uncopied parameters
CREATE TABLE LIKE is useful to create a new partition from a template
table. We can use 3 options (INCLUDING DEFAULTS, CONSTRAINTS and INDEXES)
to copy more parameters from the template, but there are still some
uncopied parameters:
1. column storage parameters (toast options)
2. reloptions on
I have some suggestions for additional psql features. I'm not planning
to work on them myself, just proposing them so others can do so if they
agree and wish to do so.
* default values for substitution values
Need a command to set the default value of a substitution variable, so
that it takes a sp
On 7/24/08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Wednesday, 23. July 2008 schrieb Marko Kreen:
> > And the idea to turn pgfoundry into CPAN
> > is pointless. An user may willing to throw random modules to his
> > random perl script, but not to his whole db architecture.
>
> Based on
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Martin Zaun wrote:
- issues locating the 14 required software packages:
- no luck getting Bison 1.875 or 2.2 Windows binaries
bison 1.875 is available here:
http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=22822
Jonah H. Harris wrote:
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
The case I'm looking at is a large table which requires a lazy vacuum,
and a zero vacuum cost delay would cause too much I/O. Yet, this
table has enough in
Hi,
Le jeudi 24 juillet 2008, Tom Dunstan a écrit :
> I guess that means you missed both the original discussion at
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php and
> my initial patch in that direction and subsequent discussion at
> http://archives.postgresql.org/pgsql-hacke
Am Wednesday, 23. July 2008 schrieb Zdenek Kotala:
> Is it fixed only on head or do you plan to backported to older branch as
> well?
I don't see a need to backport this. The only difference is that now you will
get an error if no tclsh is found. The call "configure TCLSH=..." is the
same in a
Hi,
Tom Lane wrote:
I hope you're not expecting the contents of shared memory to still be
trustworthy after a backend crash.
Hm.. that's a good point.
So I either need to bullet-proof the imessages with checksums or some
such. I'm not sure that's doable reliably. Not to speak about performan
Am Wednesday, 23. July 2008 schrieb Marko Kreen:
> And the idea to turn pgfoundry into CPAN
> is pointless. An user may willing to throw random modules to his
> random perl script, but not to his whole db architecture.
Based on what reasoning?
--
Sent via pgsql-hackers mailing list (pgsql-hacke
51 matches
Mail list logo
