Hi,
status of the patch is that it's working fine / as expected.
As is the regression test, my only concern there is if it's testing the
functionality thoroughly enough. But at it's current state I suppose it's in
line with the rest of the regression tests for dblink functionality.
Also, please
On 2009-01-14, Louis-David Mitterrand vindex+lists-pgsql-gene...@apartia.org
wrote:
Hi,
This works:
critik=# select current_timestamp::abstime::int4 as score order by
score;
This doesn't:
critik=# select current_timestamp::abstime::int4 as score order by
score + 1;
On 2009-01-14, Gerhard Heift ml-postgresql-20081012-3...@gheift.de wrote:
Hello,
is it possible to call a trigger for a row in a table without updating the
row? I want to do it in plpgsql.
Something like UPDATE table WHERE id = 10;
when faced with that problem I do this:
UPDATE table SET
On Thu, Jan 15, 2009 at 5:14 AM, Jasen Betts ja...@xnet.co.nz wrote:
On 2009-01-14, Gerhard Heift ml-postgresql-20081012-3...@gheift.de wrote:
Hello,
is it possible to call a trigger for a row in a table without updating the
row? I want to do it in plpgsql.
Something like UPDATE table WHERE
Merlin Moncure wrote:
On Thu, Jan 15, 2009 at 5:14 AM, Jasen Betts ja...@xnet.co.nz wrote:
On 2009-01-14, Gerhard Heift ml-postgresql-20081012-3...@gheift.de wrote:
Hello,
is it possible to call a trigger for a row in a table without updating the
row? I want to do it in plpgsql.
Something
Hi,
This trivial patch moves a misplaced tablespace.c call from smgr.c into
the newly created storage.c. This is appropriate because smgr.c is
supposed to be bare metal, and storage.c has the high-level calls.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
On Fri, 2009-01-09 at 19:34 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. That will reduce size of
eventual commit.
Agreed. This in particular is a change I feel
On Thu, Jan 15, 2009 at 9:14 PM, Jasen Betts ja...@xnet.co.nz wrote:
On 2009-01-14, Gerhard Heift ml-postgresql-20081012-3...@gheift.de wrote:
Hello,
is it possible to call a trigger for a row in a table without updating the
row? I want to do it in plpgsql.
Something like UPDATE table WHERE
Hitoshi Harada umi.tan...@gmail.com writes:
2009/1/15 Bruce Momjian br...@momjian.us:
Has this been addressed?
It is mentioned at
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
but not solved yet. It seems to me that to solve this the tuplestore's
inside design should be
Alvaro Herrera wrote:
Hi,
This trivial patch moves a misplaced tablespace.c call from smgr.c into
the newly created storage.c. This is appropriate because smgr.c is
supposed to be bare metal, and storage.c has the high-level calls.
None of the existing functions in storage.c have
On Thu, Jan 15, 2009 at 12:33 AM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
It seems to me ExecGrant_Relation() is a bit larger than other
ExecGrant_()s.
My preference is to clip out column-privilege part into ExecGrant_Attribute()
and invoke it for each given columns.
But, it is just my
Hitoshi Harada wrote:
2009/1/15 Bruce Momjian br...@momjian.us:
Has this been addressed?
It is mentioned at
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01849.php
* Look at tuplestore performance issues. The tuplestore_in_memory()
thing is just a band-aid, we ought to try
Heikki Linnakangas wrote:
Also, is anything being done about the concern about 'vacuum storm'
explained below?
I'm interested too.
The additional vacuum_freeze_table_age (as I'm now calling it) setting
I discussed in a later thread should alleviate that somewhat. When a
table is
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see system items. See the archives for much more
Gregory Stark wrote:
Bruce Momjian br...@momjian.us writes:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
I suggested raising it dramatically in the post you quote and Heikki pointed
it controls the maximum amount of space
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Also, is anything being done about the concern about 'vacuum storm'
explained below?
I'm interested too.
The additional vacuum_freeze_table_age (as I'm now calling it) setting
I discussed in a later thread should alleviate that somewhat. When a
--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut
pete...@gmx.net wrote:
This patch has annoyed me twice in two days now, and similarly with other
people I know. Having to type \dfS now is about the worst loss of
usability in psql that I can recall. Can we reconsider or revert
Simon Riggs wrote:
The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.
Are we talking about the same thing? If we put the control of locking to
the hands of the redo-function, I don't see why it couldn't use a lock
of the right
Peter Eisentraut wrote:
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see system items.
Simon Riggs wrote:
The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.
Hmm, grep finds two call points for that:
! case RECOVERY_TARGET_PAUSE_CLEANUP:
! /*
!
Peter Eisentraut pete...@gmx.net writes:
This patch has annoyed me twice in two days now, and similarly with
other people I know. Having to type \dfS now is about the worst loss of
usability in psql that I can recall. Can we reconsider or revert this?
I agree, this change mostly sucks, and
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see
Jaime,
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
while i'm not an official commiter/reviewer, it seems natural to me to
have an ExecGrant_Attribute() function.
Thanks for the comment. I've gone ahead and done this now, and I do
think it improves the code overall and tells a
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does,
On Thu, 2009-01-15 at 18:05 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.
Are we talking about the same thing?
I guess not. Look at the other call points for that
Bruce Momjian br...@momjian.us writes:
The basic goal of the patch was to make 'S' consistent for all \d
backslash commands, and we had a lot of discussion about it, and many
people asked for it (I can't find my user functions).
I think this falls in the category of be careful what you wish
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The basic goal of the patch was to make 'S' consistent for all \d
backslash commands, and we had a lot of discussion about it, and many
people asked for it (I can't find my user functions).
I think this falls in the category of be
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
This patch has annoyed me twice in two days now, and similarly with
other people I know. Having to type \dfS now is about the worst loss of
usability in psql that I can recall. Can we reconsider or revert this?
The problem is that you, me,
Jeff Davis wrote:
On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
If the distinction you're making is that autovacuum_freeze_max_age
affects the launching of a vacuum rather than the behavior of a vacuum,
maybe we could incorporate the word launch like:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The basic goal of the patch was to make 'S' consistent for all \d
backslash commands, and we had a lot of discussion about it, and many
people asked for it (I can't find my user functions).
I think this falls in the category of be
On Thu, Jan 15, 2009 at 7:10 AM, Bruce Momjian br...@momjian.us wrote:
Is this something for 8.4 CVS?
I worked out the patch as per Heikki's suggestion. So I think he needs
to review and decide it's fate.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent
On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I got several emails thanking me for applying the patch, so there is
clearly user-demand for 'S'. I think _we_ as developers look at the
system stuff a lot but in user-land,
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think this falls in the category of be careful what you wish for,
you might get it. It is now blindingly obvious that the folks asking
for that had not actually lived with the behavior for any period of
time.
I got several emails
Pavan Deolasee wrote:
On Thu, Jan 15, 2009 at 7:10 AM, Bruce Momjian br...@momjian.us wrote:
Is this something for 8.4 CVS?
I worked out the patch as per Heikki's suggestion. So I think he needs
to review and decide it's fate.
Yeah, I dropped the ball on that one. It's been knocking in the
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think this falls in the category of be careful what you wish for,
you might get it. It is now blindingly obvious that the folks asking
for that had not actually lived with the behavior for any period of
time.
On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane g...@turnstep.com wrote:
The problem is that you, me, and the people we know are the only ones
who actually use \df to see system functions. 99.99% of users don't care,
or don't even know, about the system functions - but they do care about
Heikki Linnakangas escribió:
Alvaro, are you getting rid of pg_autovacuum in favor of the reloptions
for 8.4?
That's the intention, yes.
This patch adds a new column to pg_autovacuum, reflecting the new
vacuum_freeze_table_age GUC just like freeze_min_age column reflects
On Thu, 2009-01-15 at 18:16 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Is the first really useful? I would understand advance until next
cleanup record *that would block/kill queries*, but why would you
want to advance until the next cleanup record?
Minor difference there, but
The basic goal of the patch was to make 'S' consistent for all \d
backslash commands, and we had a lot of discussion about it, and many
people asked for it (I can't find my user functions).
I think this falls in the category of be careful what you wish for,
you might get it. It is now
Yeah, I dropped the ball on that one. It's been knocking in the back of my
head since, but I've never gotten around. I'm feeling reluctant to review it
since it's not really a high priority thing, and I'm not sure whether we
want it or not.
In that case perhaps we should add it to
I would settle for just following the search path as set by the user.
If you explicitly include pg_catalog in the search path, then you should see
those settings.
If you do not explicitly include pg_catalog on the search_path, then it
should not find those items.
Right now pg_catalog sneaks
On Fri, Jan 16, 2009 at 03:59:47AM +1100, Brendan Jurd wrote:
Most people wanting to learn about which system functions are
available will be surely be going to the manual, not using \df?
Presently the only way you'll get a list of functions that operate on
large objects is to use \df. They
Brendan Jurd dire...@gmail.com writes:
Most people wanting to learn about which system functions are
available will be surely be going to the manual, not using \df?
I think people use \df all the time to check the argument list, verify
whether they remember the function name correctly, etc.
Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
Most people wanting to learn about which system functions are
available will be surely be going to the manual, not using \df?
I think people use \df all the time to check the argument list, verify
whether they remember the function
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
Most people wanting to learn about which system functions are
available will be surely be going to the manual, not using \df?
I think people use \df all the time to check the argument list, verify
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think people use \df all the time to check the argument list, verify
whether they remember the function name correctly, etc. It's not for
learning about stuff you never heard of, it's for remembering details
(as indeed is the usage for
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I think people use \df all the time to check the argument list, verify
whether they remember the function name correctly, etc. It's not for
learning about stuff you never heard of, it's for remembering details
(as
On Thu, Jan 15, 2009 at 09:49:59AM -0800, Joshua D. Drake wrote:
\df output wraps at 1024x768 which greatly limits usability as a whole.
I hadn't noticed this until today as my workstation video card exploded
and I have a temporary one that can't do more than 1024x768 with linux.
Dropping the
Rod Taylor rod.tay...@gmail.com writes:
Right now pg_catalog sneaks its way onto the search_path for everybody. That
is fine for execution but information listing like this should probably
ignore those additions.
Actually, the single worst, most misleading, pernicious and dangerous
aspect of
Bruce Momjian br...@momjian.us writes:
Well, this is psql and it should be easy; I am not sure pg_catalog.*
fits that requirement.
It should be easy for common cases, which I argue I need to see *only*
system objects is not.
Right now if you do \dt you see user tables, and
\dtS shows system
I think searching for both user and system stuff with a pattern is a
no-brainer.
I'm not sure whether you're endorsing that approach or panning it, but
-1 from me. We have always had \d or \dt for user tables and \dS or
\dtS for system tables. No one is complaining about this AFAICS, so
we
How many of the people who find the new behaviour are mainly postgres
hackers and not users?
I remember finding the behaviour *very* frustrating when I was a user
and was mainly concerned with maintaining my own functions. I hardly
ever used \df for system functions.
Now the situation is
BTW, it might be worth pointing out that \d has never worked like that;
for instance \d pg_class gives me an answer anyway. So holding up the
table behavior as a model of consistency that other \d commands should
emulate is a pretty weak argument to begin with.
So in 8.3.5, which is what I
On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Well, this is psql and it should be easy; I am not sure
pg_catalog.* fits that requirement.
It should be easy for common cases, which I argue I need to see
*only* system objects is not.
Robert Haas robertmh...@gmail.com writes:
However, having said that, I'm not averse to unifying the behavior
as long as it's done in a sensible fashion. Imposing the old behavior
of \dt on everything else is simply not that sensible fashion.
Do you have another proposal?
Although I agree
On Thu, Jan 15, 2009 at 01:46:08PM -0500, Robert Haas wrote:
I know I already posted this but it seems the most useful behavior is to
just change the sort. It doesn't change any behavior in terms of
flags/switches so there is nothing new to learn. It just changes the
output.
That's
David Fetter da...@fetter.org writes:
On Thu, Jan 15, 2009 at 01:46:08PM -0500, Robert Haas wrote:
That's better than nothing, but it still doesn't help when I want to do:
psql -c '\df' | grep bool
psql -c '\dfS' |grep bool
That presumes the opposite case, when you only want to see system
Tom,
The real problem here is that the 'S' suffix for \dt is a bad precedent
for everything else. If you want consistency then we need to change
that end of things. I think that the idea of a switch to omit system
objects, rather than include them, might work.
I disagree. Most users, most
Le 15 janv. 09 à 17:16, Tom Lane t...@sss.pgh.pa.us a écrit :
Peter Eisentraut pete...@gmx.net writes:
This patch has annoyed me twice in two days now, and similarly with
other people I know. Having to type \dfS now is about the worst
loss of
usability in psql that I can recall. Can we
Josh Berkus j...@agliodbs.com writes:
I disagree. Most users, most of the time, do not want to see system
objects.
I remain of the opinion that this opinion is wrong, and is based on
lack of experience with the committed patch.
You *think* you don't want to see system objects. The first
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 15 janv. 09 à 17:16, Tom Lane t...@sss.pgh.pa.us a écrit :
I agree, this change mostly sucks, and particularly with respect to
\df.
Maybe it does so much 'cause you're developing system functions.
No, I hardly ever use \df on a function
Le 15 janv. 09 à 21:39, Tom Lane t...@sss.pgh.pa.us a écrit :
\dfS together with \dfU would at least be a reasonably symmetric
extension. I'm still of the opinion that neither is really a very
helpful thing to use in connection with a pattern.
I completly agree with the idea of showing things
Hey all,
I recently had pg_dump produce a non-restorable dump for one of my
databases. I can't share the dump itself, but I can describe what
went wrong.
This database had a user-defined composite type in it. I wanted to be
able to GROUP BY this type, so I added a family of comparison
On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus j...@agliodbs.com wrote:
The real problem here is that the 'S' suffix for \dt is a bad precedent
for everything else. If you want consistency then we need to change
that end of things. I think that the idea of a switch to omit system
objects,
Robert Haas robertmh...@gmail.com writes:
I'm not sure whether you're endorsing that approach or panning it, but
-1 from me. We have always had \d or \dt for user tables and \dS or
\dtS for system tables. No one is complaining about this AFAICS, so
we should \df be any different? The only
Tom,
You *think* you don't want to see system objects. The first time that
you waste hours trying to figure out why your function doesn't work,
only to find that it conflicts with a system function that \df wasn't
showing you, you'll reconsider.
I'm still a consultant for a living, so I use
I wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not sure whether you're endorsing that approach or panning it, but
-1 from me. We have always had \d or \dt for user tables and \dS or
\dtS for system tables. No one is complaining about this AFAICS, so
we should \df be any different?
Josh Berkus j...@agliodbs.com writes:
You *think* you don't want to see system objects.
I'm still a consultant for a living, so I use the psql command line on a
variety of client systems a lot. And I'll tell you that 80% of the time
I use \df it's to look up the exact spelling and
I know I already posted this but it seems the most useful behavior is to
just change the sort. It doesn't change any behavior in terms of
flags/switches so there is nothing new to learn. It just changes the
output.
That's better than nothing, but it still doesn't help when I want to do:
psql
You're ignoring the fact that tables and functions are different and
are used differently. In particular, most of the system catalogs are
not really meant to be used directly by users, which is surely not
true for functions and operators.
However, having said that, I'm not averse to
Tom,
I'm unimpressed with the idea of a \system switch, because it will still
be breaking your \df queries hours after you forgot you used it to
adjust \dt. (This argument holds no matter which way you prefer as
default.)
H, OK.
BTW, is this patch even under consideration for 8.4? If
Brendan Jurd dire...@gmail.com writes:
I recently had pg_dump produce a non-restorable dump for one of my
databases. I can't share the dump itself, but I can describe what
went wrong. ...
* It seems there's no pg_depend entry for
types/functions/operators/opclasses that the view depends on,
On Thu, 2009-01-08 at 22:31 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
If you want to do things a different way you need to say what you want
to do and what effects those changes will have.
I want to reduce the coupling between the primary and the master. The
less they need to
2. You want to write \df something. Fine, that's not going to show
any system functions anyway, unless there are system functions that are
also selected by something. If there are, it's not apparent to me why
it's a bad idea to show them; as I've already argued, I think not
showing them is
Josh Berkus j...@agliodbs.com writes:
BTW, is this patch even under consideration for 8.4?
It's already committed --- remember the start of the thread was Peter
complaining that he'd already been annoyed by the new behavior. (As
had I, but I'd not gotten round to complaining yet.)
If we wait
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock
library, adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so do
the ref counts and winsock is
* Robert Haas (robertmh...@gmail.com) wrote:
On the other hand, I want to look at and search my user-defined
functions FREQUENTLY. I don't care about the system functions. If I
type \df a*, it's not because I want to see all 6 versions of the
absolute value function and 61 other functions,
Robert Haas robertmh...@gmail.com writes:
You seem to be assuming that conflicts between user-defined functions
and system functions are a common problem against which users need
protection. I have been using PostgreSQL for almost 10 years and am
not sure that I've EVER had a problem with
Tom,
Well, maybe we do need to go with the \df \dfS \dfU approach.
But I'm still convinced that setting things up so that it's impossible
to search both classes of functions together is a seriously bad idea.
Agreed -- there are times I *want* to search the system functions, and
for
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock
library, adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so do
the ref counts and winsock is
On the other hand, I want to look at and search my user-defined
functions FREQUENTLY. I don't care about the system functions. If I
type \df a*, it's not because I want to see all 6 versions of the
absolute value function and 61 other functions, it's because I don't
want to think hard
On Thu, 2009-01-15 at 14:32 -0800, Josh Berkus wrote:
Tom,
Personally, I don't care that much about what Hungarian Notation we use,
as long as we try to make it consistent with \dt, \dv, \dn etc. My main
objection to requiring \dfU to get only user functions is that it's not
what we do
On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
* It seems there's no pg_depend entry for
types/functions/operators/opclasses that the view depends on, unless
they are part of the SELECT list.
What PG version exactly? We've been
Josh Berkus j...@agliodbs.com writes:
Well, maybe we do need to go with the \df \dfS \dfU approach.
But I'm still convinced that setting things up so that it's impossible
to search both classes of functions together is a seriously bad idea.
Agreed -- there are times I *want* to search the
Brendan Jurd dire...@gmail.com writes:
On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
* It seems there's no pg_depend entry for
types/functions/operators/opclasses that the view depends on, unless
they are part of the SELECT list.
On Thu, 2009-01-15 at 22:10 +, Simon Riggs wrote:
I notice that we are no longer able to record the databaseId for a
connection, so query conflict resolution cannot be isolated to
individual databases any longer.
Wrong way round. Incoming WAL records from dbOid on them, so we can
still
* Joshua D. Drake (j...@commandprompt.com) wrote:
I like this behavior. A lot.
ditto.
That was a little irritating but I get the point. The schema functions
is not in my search path. So:
That's exactly right, imv.. I've got schemas with tons of functions in
them, I don't want to see every
Stephen,
On a seperate (kind of) note, I'd really like to be able to say I want
this function visible everywhere like a system function. public really
doesn't fit this bill very well, in my experience.
We're *so* not going there. If you really want this, just log in as
superuser and add
Stephen Frost sfr...@snowman.net writes:
gah, I find that to be terrible. If we wanted to compromise, I'd
rather have \df do what it does today, to keep backwards-compat and
not confuse users, and \dfU to do what I want 99% of the time.
This seems to me to be the compromise most likely to
On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
gah, I find that to be terrible. If we wanted to compromise, I'd
rather have \df do what it does today, to keep backwards-compat and
not confuse users, and \dfU to do what I want 99% of the time.
On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
gah, I find that to be terrible. If we wanted to compromise, I'd
rather have \df do what it does today, to keep backwards-compat and
not confuse users, and \dfU to do what I want 99%
All,
But I may be trying to push water up a hill, so, I can live with
adding \dfU and keeping \df as-was.
BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
\JosH
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
* Josh Berkus (j...@agliodbs.com) wrote:
But I may be trying to push water up a hill, so, I can live with
adding \dfU and keeping \df as-was.
BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
I havn't got much of a preference for \dfu vs. \dfU. Either works for
me.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
On a seperate (kind of) note, I'd really like to be able to say I want
this function visible everywhere like a system function.
Huh? System functions don't have that property either.
Perhaps I'm missing
Josh Berkus j...@agliodbs.com writes:
But I may be trying to push water up a hill, so, I can live with
adding \dfU and keeping \df as-was.
BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
Because (1) its counterpart S is capitalized by historical tradition,
and (2) we
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
On a seperate (kind of) note, I'd really like to be able to say I want
this function visible everywhere like a system function. public really
doesn't fit this bill very well, in my experience.
We're *so* not going there. If you really want
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus j...@agliodbs.com writes:
But I may be trying to push water up a hill, so, I can live with
adding \dfU and keeping \df as-was.
BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
Because (1) its counterpart S is
Stephen Frost sfr...@snowman.net writes:
Regardless of what I reset my search_path to, I'm going to have access
to abstime. Is there something else special about it besides being
a 'system function' and being in pg_catalog to make it always available
regardless of my search_path?
Read the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Read the documentation for search_path: if pg_catalog isn't explicitly
mentioned, we add it implicitly. This is mainly because it would be
contrary to SQL spec (and pretty useless to boot) to not recognize the
standard functions and operators. But
Stephen Frost sfr...@snowman.net writes:
As I mentioned in my other email, this is mainly for PostGIS, but it can
certainly apply to other modules. Is this what we would recommend as an
approach for these kinds of modules? I feel like that would give
-hackers, or perhaps the PostGIS people,
1 - 100 of 107 matches
Mail list logo
