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
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;
> ERROR: column "score"
On 2009-01-14, Gerhard Heift 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 id=id WHERE id = 10;
--
Sent vi
On Thu, Jan 15, 2009 at 5:14 AM, Jasen Betts wrote:
> On 2009-01-14, Gerhard Heift 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
Merlin Moncure wrote:
On Thu, Jan 15, 2009 at 5:14 AM, Jasen Betts wrote:
On 2009-01-14, Gerhard Heift 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 pr
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/
Postgr
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 f
On Thu, Jan 15, 2009 at 9:14 PM, Jasen Betts wrote:
> On 2009-01-14, Gerhard Heift 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
"Hitoshi Harada" writes:
> 2009/1/15 Bruce Momjian :
>> 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 changed much. In-file state
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 SMgrRelation
On Thu, Jan 15, 2009 at 12:33 AM, KaiGai Kohei 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 preference. Pl
Hitoshi Harada wrote:
> 2009/1/15 Bruce Momjian :
> >
> > 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 to s
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
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
di
Gregory Stark wrote:
> Bruce Momjian 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 the clo
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
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 this?
I'd lik
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 stre
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 sys
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 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 particularly
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 bett
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)
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 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 for,
you might
Tom Lane wrote:
> Bruce Momjian 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 w
-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, m
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:
autovacuum_launch_freeze_th
Tom Lane wrote:
> Bruce Momjian 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
On Thu, Jan 15, 2009 at 7:10 AM, Bruce Momjian 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 via pgsql-hac
On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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, they would ra
Bruce Momjian 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 thanking
Pavan Deolasee wrote:
On Thu, Jan 15, 2009 at 7:10 AM, Bruce Momjian 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 back of
my head
Tom Lane wrote:
> Bruce Momjian 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 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
> being able to
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
> vacuum_free
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, b
>> > 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
> 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
http://w
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 its
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 m
"Brendan Jurd" 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. It's not for
"le
Tom Lane wrote:
> "Brendan Jurd" 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 corre
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
> "Brendan Jurd" 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 th
Bruce Momjian 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 user-
Tom Lane wrote:
> Bruce Momjian 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 i
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 t
Rod Taylor 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 the currently commi
Bruce Momjian 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 tables; I
> 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 s
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 wha
On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote:
> Bruce Momjian 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.
Neither is
"Robert Haas" 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 with you that
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.
>
> Th
David Fetter 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
functions.
I
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 o
Le 15 janv. 09 à 17:16, Tom Lane a écrit :
Peter Eisentraut 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 agre
Josh Berkus 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 time that
you waste
Dimitri Fontaine writes:
> Le 15 janv. 09 à 17:16, Tom Lane 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 I'm working on just at the
moment,
Le 15 janv. 09 à 21:39, Tom Lane 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 respecting current
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
functions
On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus 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, rather than in
"Robert Haas" 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 argument I can se
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 t
I wrote:
> "Robert Haas" 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?
> You're ig
Josh Berkus 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 parameters of a
> us
> 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:
p
> 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 un
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 no
"Brendan Jurd" 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, unless
> t
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
> 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
Josh Berkus 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 till after 8.4 is
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 automatical
* 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 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 this.
Probably not,
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 less-train
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 automatical
>> 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 h
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
On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane wrote:
> "Brendan Jurd" 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 moving towards fuller
> rep
Josh Berkus 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 system functio
"Brendan Jurd" writes:
> On Fri, Jan 16, 2009 at 9:01 AM, Tom Lane wrote:
>> "Brendan Jurd" 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?
> This
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 ever
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 t
Stephen Frost 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 dissatisfy everyone
On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote:
> Stephen Frost 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 seem
On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane wrote:
> Stephen Frost 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
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 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 something, or i
Josh Berkus 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 are going to a
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus 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 capitaliz
Stephen Frost 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 documentation for
* 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 be
Stephen Frost 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, some heartburn,
1 - 100 of 107 matches
Mail list logo
