I am sorry for not elaborating on that. What I meant by de-correlation was
optimizing a query to get rid of sub-queirs by using joins.
eg. In the TPC-H schema, a query to find out the names of suppliers who
supply parts having size < 100
*Query with nested subqueries:*
SELECT
S_NAME
FROM
Robert Haas wrote:
> I think the best thing for this patch right now is to move it to
> "Returned with Feedback". I can't see any way that this patch is
> going to be made committable for this CommitFest, and I think that
> pretending otherwise is only encouraging KaiGai to do another of his
> lig
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
I've described it from the scratch again with paying attention
for the people knowing nothing about SELinux.
In some points, it uses comparison between the database privilege
mechanism
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
> The only thing I don't like about this is that I think it's kind of a
> hack to shove the in transaction designation and the query
> string into the same database column. I've never liked having to
> write:
>
> select sum(1) from pg_
Hi,
While trying out query executions using the geqo, I could not understand the
following output.
The geqo paramaters are set to default values. (pool_size=0).
When the pool_size and the worth of the plans was displayed, the following
values were obtained, irrespective of the number of rel
2009/7/24 David E. Wheeler :
> ROW(1, NULL) is neither NULL nor NOT NULL. I've no idea what state it is,
> but I guess that's the standard.
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
It doesn't really make sense to talk about the ROW itself being NU
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas wrote:
> Here's my first attempt at setting client_encoding automatically from
> locale.
>
Sorry for the many mails on this issue.. i will do a recolect of my findings:
1) it introduces a dependency for -lpgport when compiling a client
that uses
On Jul 23, 2009, at 6:52 PM, David E. Wheeler wrote:
No, that's not the problem I see -- that solved the problem in my
particular code. The problem I see is that, given that the standard
says (according to Tom) that if any value is NULL then the record is
NULL, then I would expect this to r
On Jul 23, 2009, at 6:06 PM, Jeff Davis wrote:
However, in step 2, you transformed:
x IS NOT NULL => NOT x IS NULL
But in SQL that is not a tautology!
No, that's not the problem I see -- that solved the problem in my
particular code. The problem I see is that, given that the standard
say
On Jul 23, 2009, at 6:21 PM, Greg Stark wrote:
Are they not both null?
Isn't that just what you were complaining about not being the case:
Yes, but given that the standard says that `ROW(1, NULL)` is NULL,
then I would expect it to be NOT DISTINCT from `ROW(2, NULL)`.
Best,
David
--
Se
On Sat, Jul 18, 2009 at 12:06 PM, David Fetter wrote:
> At this point, SE-PostgreSQL has taken up a *lot* of community
> resources, not to mention an enormous and doubtless frustrating amount
> of Kohei-san's time and effort, thus far without a single committed
> patch, or even a consensus as to wh
On Fri, Jul 24, 2009 at 1:32 AM, David E. Wheeler wrote:
> On Jul 23, 2009, at 4:22 PM, Tom Lane wrote:
>
>> Dunno how you can possibly come to that conclusion. Those row
>> values are certainly distinct (according to both PG and the spec).
>
> Are they not both null?
Isn't that just what you wer
Itagaki Takahiro wrote:
> Greg Smith wrote:
> > That second code path, when --enable-thread-safety is turned off, crashes
> > and burns on my Linux system:
>
> It comes from confliction of identifiers.
> Renaming identifiers with #define can solve the errors:
> #define pthread_t
On Thu, 2009-07-23 at 17:32 -0700, David E. Wheeler wrote:
> On Jul 23, 2009, at 4:22 PM, Tom Lane wrote:
>
> > Dunno how you can possibly come to that conclusion. Those row
> > values are certainly distinct (according to both PG and the spec).
>
> Are they not both null?
[ Is that a play on wo
mahendra chavan wrote:
> I am a master's student in computer science at IIT Bombay. As part of my
> project, I need to get a decorrelated version of a SQL query. Please could
> anyone let me know if we have query decorrelation feature implemented in
> postgres ?
What do you mean by "query deco
On Jul 23, 2009, at 3:33 PM, Jeff Davis wrote:
not ROW(1, NULL) is null and not ROW(1, NULL) is not null
I don't know what the SQL standard says about this
Thanks Jeff, that's just what I needed.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On Jul 23, 2009, at 4:22 PM, Tom Lane wrote:
Dunno how you can possibly come to that conclusion. Those row
values are certainly distinct (according to both PG and the spec).
Are they not both null?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Brendan Jurd escreveu:
> 2009/4/26 Brendan Jurd :
>> I've done some work updating Pavel's sci notation patch for to_char().
>
> That patch again, now with a couple of minor tweaks to make it apply
> cleanly against the current HEAD.
>
Here is my review. The patch applied without problems. The doc
"David E. Wheeler" writes:
> And yet they're DISTINCT FROM each other if either or both contain
> NULLs and some other values?
Well, that would depend on what the values were and in what columns...
> It seems to me that, to be consistent, it
> should be:
> select ROW(1, NULL) IS DISTIN
On Jul 23, 2009, at 4:08 PM, Tom Lane wrote:
This is per SQL standard. IS NULL is true if *all* the record's
fields are null; IS NOT NULL is true if *none* of them are.
Yeah, it's a bit dubious, but that's what they said.
And yet they're DISTINCT FROM each other if either or both contain
N
"David E. Wheeler" writes:
> How can a record be neither NULL or NOT NULL?
This is per SQL standard. IS NULL is true if *all* the record's
fields are null; IS NOT NULL is true if *none* of them are.
Yeah, it's a bit dubious, but that's what they said.
regards, tom lane
Andrew Dunstan writes:
> I'll work on it, but for now I propose to make the following change to
> configure.in and the corresponding change in configure:
I believe you can just add AC_LIBOBJ(erand48) in the Cygwin-specific
section without touching the other part; that's supposed to be a no-op
if
Brendan Jurd writes:
> I've also done an initial review of the patch. Everything looks sane
> and the patch works as advertised. I made a couple of minor tweaks
> for code-style and comment consistency, and my version 3 is attached.
> I'm marking this patch Ready for Committer.
Applied with mi
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Hmm. So we need to figure out how to improve configure's check so that
it rejects whatever broken version you've got ...
Yeah. Any ideas? I'd hate just to exclude the system erand48 on Cygwin
and then find out late
On Thu, 2009-07-23 at 15:19 -0700, David E. Wheeler wrote:
> How can a record be neither NULL or NOT NULL?
You could do:
not ROW(1, NULL) is null and not ROW(1, NULL) is not null
I don't know what the SQL standard says about this.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
On Jul 23, 2009, at 3:19 PM, David E. Wheeler wrote:
How can a record be neither NULL or NOT NULL?
try=# select ROW(1, NULL) IS NULL;
?column?
--
f
(1 row)
try=# select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
This makes it rather hard
http://github.com/jwp/postgresql-plpython3/tree/plpython3 [branch
name: plpython3]
[src/pl/plpython3] (Yeah, I'm going to try to move it to
git.postgresql.org soon-ish)
In a recent thread[1], Peter said:
That also means that maintaining a separate, parallel code base
for a Python 3
How can a record be neither NULL or NOT NULL?
try=# select ROW(1, NULL) IS NULL;
?column?
--
f
(1 row)
try=# select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
This makes it rather hard to tell, in PL/pgSQL, when I've fetched the
Andrew Dunstan writes:
> Tom Lane wrote:
>> Hmm. So we need to figure out how to improve configure's check so that
>> it rejects whatever broken version you've got ...
> Yeah. Any ideas? I'd hate just to exclude the system erand48 on Cygwin
> and then find out later it's broken on some other a
Peter Eisentraut wrote:
On Thursday 23 July 2009 06:26:05 Petr Jelinek wrote:
I'd still like to have opinion from one of the commiters on "the
VIEW problem" which also affects grant on all patch ( see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and
I fear "returned wit
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas wrote:
> Here's my first attempt at setting client_encoding automatically from
> locale.
>
when i apply your patch and try to compile in windows i get this error
dllwrap -o libpq.dll --dllname libpq.dll --def ./libpqdll.def
fe-auth.o fe-connec
I wrote:
> Anyway, I'll go take a look at exactly what would be involved in the
> first choice.
Actually, it seems this way results in a net *savings* of code, because
we can simply remove the code that was responsible for retail pfree'ing
of the transition values. I suppose that code must have p
2009/7/23 Bernd Helmle :
> --On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
> wrote:
>
>> Hello
>>
>> I did some cleaning on this feature, and I hope so I solve some Tom's
>> objections
>>
>> features:
>> * PostgreSQL's specific syntax for named parameter: value AS name,
>> * Doesn't
--On Donnerstag, März 05, 2009 08:41:28 +0100 Pavel Stehule
wrote:
Hello
I did some cleaning on this feature, and I hope so I solve some Tom's
objections
features:
* PostgreSQL's specific syntax for named parameter: value AS name,
* Doesn't change rules for defaults,
* Get defaults for na
On Thu, Jul 23, 2009 at 1:24 PM, Peter Eisentraut wrote:
>
> Which proves my point, because libpgport includes chkconfig.c. But this is
> just a workaround.
>
yeah! actually the problem i had was because we need to add the
-lpgport to use pg_get_encoding_from_locale and that is something that
thi
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
I see it claims to have working erand48, but maybe not so much in
reality?
Good guess. I removed erand48 from the configure file and added
erand48.o to OBJS in src/port/Makefile and it suddenly sailed through.
Greg Stark writes:
> Rereading your diagnosis of Merlin Moncure's original problem I'm a
> bit puzzled. Why do we have to rerun the final function when we rescan
> the hash table? Surely the logical thing to do is to store the final
> value in the hash table with some flag saying that value has be
Hitoshi Harada writes:
> So two ideas from Tom seem to me a little worse than that. Modifying
> Agg.c might add overhead to reset context group by group and forcing
> array_agg() (i.e. user aggregates) to distinguish hash-mode and
> group-mode is definitely heavy for users.
I agree that the secon
On Thu, Jul 23, 2009 at 11:05 AM, David E. Wheeler wrote:
> On Jul 23, 2009, at 4:08, Robert Haas wrote:
>
>> Yes... but "if" and "just" can paper over a good deal of complexity, and
>> it's not clear to me that there's any compensating advantage.
>
> It seems reasonable not to worry about this is
On Thursday 23 July 2009 20:16:39 Jaime Casanova wrote:
> On Thu, Jul 23, 2009 at 11:02 AM, Tom Lane wrote:
> > On most Linux systems, -L doesn't have any effect on what happens at
> > runtime --- the dynamic linker's search path will determine that.
> > Try "ldd" on the executable to see which shl
On Thu, Jul 23, 2009 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> Ugh. I took a look at this and it turns out that there are some
>> tentacles. It doesn't seem very sane to actually do anything with a
>> list of DefElem nodes, so we really need to parse that list and
>> convert it to a
Andrew Dunstan writes:
> Tom Lane wrote:
>> I see it claims to have working erand48, but maybe not so much in
>> reality?
> Good guess. I removed erand48 from the configure file and added
> erand48.o to OBJS in src/port/Makefile and it suddenly sailed through.
Hmm. So we need to figure out ho
Tom Lane wrote:
I see it claims to have working erand48, but maybe not so much in
reality?
Good guess. I removed erand48 from the configure file and added
erand48.o to OBJS in src/port/Makefile and it suddenly sailed through.
cheers
andrew
--
Sent via pgsql
On Jul 23, 2009, at 9:09 AM, Andrew Dunstan wrote:
Please particularly see this sentence: "But unless someone wants to
tackle that I think we should leave schema management entirely
alone, and leave it up to the extension author / DBA between them."
I think we are in some danger of massivel
On Thu, Jul 23, 2009 at 11:02 AM, Tom Lane wrote:
>
> On most Linux systems, -L doesn't have any effect on what happens at
> runtime --- the dynamic linker's search path will determine that.
> Try "ldd" on the executable to see which shlibs really get picked up.
>
yeah! it's using the one that shi
On Jul 23, 2009, at 8:09 AM, Dimitri Fontaine wrote:
What about embedded calls in, say, plperl functions.
Hence the variable suggestion. In fact, it might go back to the idea
of subschemas, perhaps the name of the extension should be part of the
qualifying? I dunno, I'm just kind of throwi
Mark Kirkwood writes:
> Yeah, enabling log_lock_waits is certainly another approach, however you
> currently miss out on those that are < deadlock_timeout - and
> potentially they could be the source of your problem (i.e millions of
> waits all < deadlock_timeout but taken together rather signi
Dimitri Fontaine wrote:
Richard Huxton writes:
INSTALL chinese_calendar;
IMPORT FROM chinese_calendar SECTION (default) INTO SCHEMA pg_extension;
IMPORT FROM chinese_calendar SECTION (year_names) INTO SCHEMA lookups;
Please see Andrew Dunstan mail about using some notion of ALIAS (i
Robert Haas writes:
> Ugh. I took a look at this and it turns out that there are some
> tentacles. It doesn't seem very sane to actually do anything with a
> list of DefElem nodes, so we really need to parse that list and
> convert it to a more sensible format right away (this also seems
> impor
Jaime Casanova writes:
> On Wed, Jul 22, 2009 at 7:30 PM, Alvaro
> Herrera wrote:
>> Do you have an older version of libpq.so around?
> the one that installed with 8.4.0 but i thougth that when you specify
> -L to gcc you're telling it where to pick libraries from, no?
On most Linux systems, -L
"David E. Wheeler" writes:
> Part of the behavior of CREATE EXTENSION would be to automatically
> schema-qualify references to objects in the extension. Or perhaps
> extension authors would need to use some sort of variable for the schema
> that would be properly resolved when CREATE EXTENSION i
On Jul 23, 2009, at 4:08, Robert Haas wrote:
Yes... but "if" and "just" can paper over a good deal of complexity,
and it's not clear to me that there's any compensating advantage.
It seems reasonable not to worry about this issue in the first rev, or
at least not to let it stop development
On Jul 23, 2009, at 2:11, Dimitri Fontaine
wrote:
Well the problem with that is if for example I define foo() and bar()
functions in my extension, and the user also has a foo() function in
his
own stuff (possibly lying in public, say).
Now if in my extenion in function bar() I call foo(),
Laurent Laborde wrote:
> (iostat show a 5~25MB/s bandwidth at 100%util instead of 2~5MB/s at
> 100%util).
Any numbers for overall benefit at the application level?
> So... now i'm not sure anymore about lowering the tuple per page
> om 4 to 8.
> Doing that would mean more data in TOAST tab
Andrew Dunstan writes:
> Tom Lane wrote:
>> I wonder if it would be helpful to have a buildfarm option whereby
>> it would fetch the latest nightly-snapshot tarball and use that instead
>> of a CVS pull.
> That is certainly doable. It would be in effect a forced run, because we
> would have no n
Tom Lane wrote:
Andrew Dunstan writes:
Magnus Hagander wrote:
Much as I dislike it, we may need to revisit the idea about putting
the flex output files in CVS...
Why? This only affects developers building from a CVS pull. You don't
need any flex at all to build from a ta
Andrew Dunstan writes:
> Magnus Hagander wrote:
>> Much as I dislike it, we may need to revisit the idea about putting
>> the flex output files in CVS...
> Why? This only affects developers building from a CVS pull. You don't
> need any flex at all to build from a tarball. If developers can't
>
Michael Meskes írta:
> On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote:
>
>> as asked by Michael Meskes, I have split up our ECPG patchset:
>>
>
> Just a couple quick comments.
>
> It appears to me (without much testing) that the patches still partly rely on
> each other.
2009/7/23 Greg Stark :
> On Wed, Jul 22, 2009 at 10:14 PM, Tom Lane wrote:
>> The reason for that turns out to be that we deliberately lobotomized
>> array_agg that way, just last month:
>> http://archives.postgresql.org/pgsql-committers/2009-06/msg00259.php
>> in response to this problem:
>> http:
Richard Huxton writes:
> INSTALL chinese_calendar;
> IMPORT FROM chinese_calendar SECTION (default) INTO SCHEMA pg_extension;
> IMPORT FROM chinese_calendar SECTION (year_names) INTO SCHEMA lookups;
Please see Andrew Dunstan mail about using some notion of ALIAS (is that
a standard compliant SYNO
Peter Eisentraut writes:
> On Tuesday 23 June 2009 20:44:39 Dimitri Fontaine wrote:
> Instead of installing an "extension", that is, say, a collection of types and
> functions provided by a third-party source, I would like to have a mechanism
> to deploy my own actual database application code.
Hello,
I am a master's student in computer science at IIT Bombay. As part of my
project, I need to get a decorrelated version of a SQL query. Please could
anyone let me know if we have query decorrelation feature implemented in
postgres ?
Thanks,
Mahendra Chavan
Robert Haas writes:
> On Jul 23, 2009, at 2:44 AM, "David E. Wheeler"
> wrote:
>>
>> Well, it depends. If there could be some sort of defined interface for
>> pg_migrator could call to migrate any data type (this issue applies
>> mainly to types, yes?), then an extension author just needs to im
On Wed, Jul 22, 2009 at 10:54 AM, Laurent Laborde wrote:
> My 1st applied patch is the safest and simpliest :
> in pg_lzcompress.c :
>
> static const PGLZ_Strategy strategy_default_data = {
> 256, /* Data chunks less than 256 are not compressed */
> 256, /* force compression on
On Jul 23, 2009, at 2:44 AM, "David E. Wheeler"
wrote:
On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than a kick in the head.
Peter Eisentraut wrote:
> Instead of installing an "extension", that is, say, a collection
> of types and functions provided by a third-party source, I would
> like to have a mechanism to deploy my own actual database
> application code.
On the matter of schemas, I suggest that we consider two i
On Tuesday 23 June 2009 20:44:39 Dimitri Fontaine wrote:
> === installing and removing an extension
>
> begin;
> install extension foo with search_path = foo;
> commit;
>
> Extensions authors are asked not to bother about search_path in their sql
> scripts so that it's easy for DBAs to decide
Tom Lane schrieb:
Andreas Wenk writes:
I am not sure when the function shobj_description(oid, name) is giving a
result.
That retrieves the comment for the object (the role, in this case).
regards, tom lane
attached you can find an updated patch. The changes are:
-
On Thursday 23 July 2009 06:26:05 Petr Jelinek wrote:
> I'd still like to have opinion from one of the commiters on "the
> VIEW problem" which also affects grant on all patch ( see
> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and
> I fear "returned with feedback" might prev
On Thursday 23 July 2009 02:29:23 Jaime Casanova wrote:
> this little test compiles fine until i applied your patch :(
>
> postg...@casanova1:~/pg_releases/pgtests$ gcc -o test-libpq
> test-libpq.o -L/usr/local/pgsql/head/lib -lpq
> /usr/local/pgsql/head/lib/libpq.so: undefined reference to
> `pg_g
Magnus Hagander wrote:
On Thu, Jul 23, 2009 at 10:52, Dave Page wrote:
On Thu, Jul 23, 2009 at 2:57 AM, Greg Smith wrote:
I got bit by this tonight as part of testing a patch on CentOS 5, which like
RHEL 5 still ships flex 2.5.4. I just wrote a little guide on how to grab a
source RP
"David E. Wheeler" writes:
> On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:
>> Easy answer for first version: don't allow user to install extension in
>> another place than what we think will better suit him, and that's the
>> new schema pg_extension, which always lies just before pg_catalog
On Thu, Jul 23, 2009 at 10:52, Dave Page wrote:
> On Thu, Jul 23, 2009 at 2:57 AM, Greg Smith wrote:
>> I got bit by this tonight as part of testing a patch on CentOS 5, which like
>> RHEL 5 still ships flex 2.5.4. I just wrote a little guide on how to grab a
>> source RPM from a Fedora version an
On Thu, Jul 23, 2009 at 2:57 AM, Greg Smith wrote:
> I got bit by this tonight as part of testing a patch on CentOS 5, which like
> RHEL 5 still ships flex 2.5.4. I just wrote a little guide on how to grab a
> source RPM from a Fedora version and install it to work around that problem:
> http://no
On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:
Easy answer for first version: don't allow user to install extension
in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in
the
search_path.
Well, I
Currently, libpq will wrap each send() call on the connection with
two system calls to mask SIGPIPEs. This results in 3 syscalls instead
of one, and (on Linux) can lead to high contention on the signal
mask locks in threaded apps.
We have a couple of other methods to avoid SIGPIPEs:
sockopt(SO_NOS
Hi,
"David E. Wheeler" writes:
> On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:
>> - how to give user the ability to install the extension's objects in
>> another schema than the pg_extension default one
>
> And just allow it to take a schema-qualified argument like any other SQL
> command
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes - quite
true. I was thinking it is useful to be able to answer the question 'where
is my wait time being spent' - but it hides cases like the one you
I wrote:
> How about export dtrace functions as hook function pointers?
Here is a proposal to integrate profiler to postgres without adding
any tracing markers. The goal is to provide platform-independent
and easy-to-use performance profiler. (typically just adding some
configuration to postgresql
On Thu, Jul 23, 2009 at 08:04, Tsutomu Yamada wrote:
> Hello,
>
> Thank you for correcting patch.
> However, I think the following block have to use VirualFree*Ex*().
>
> (yes, this should never happen, maybe there is actually no problem.
> but for logical correctness)
That is definitely correct.
80 matches
Mail list logo
