Bruce Momjian writes:
> Sorry, this is the right one:
> SELECT n.nspname, c.relname, a.attname, d.adsrc
> FROMpg_namespace n, pg_class c, pg_attribute a, pg_attrdef d
> WHERE n.oid = c.relnamespace AND
> c.oid = a.attrelid AND
> a.attrelid = d.
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Does that sound like a workable compromise?
> >
> > > Personally, I _love_ it. I hope others do as well. :-)
> >
> > OK, I'll work up a patch.
>
> Here is a query that shows nextval(::text) usage as
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Does that sound like a workable compromise?
>
> > Personally, I _love_ it. I hope others do as well. :-)
>
> OK, I'll work up a patch.
Here is a query that shows nextval(::text) usage as defaults:
SELECT n.nspname, c.r
Bruce Momjian writes:
> Tom Lane wrote:
>> Does that sound like a workable compromise?
> Personally, I _love_ it. I hope others do as well. :-)
OK, I'll work up a patch.
regards, tom lane
---(end of broadcast)---
TIP 5:
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Ripping out ALTER SCHEMA RENAME is not a solution unless you have a path
> >> to a solution later with more work.
>
> > Well, we are only giving ourselves a few weeks to solve this, and I
> > think a hack to make it work cleanly for
Bruce Momjian writes:
> Tom Lane wrote:
>> Ripping out ALTER SCHEMA RENAME is not a solution unless you have a path
>> to a solution later with more work.
> Well, we are only giving ourselves a few weeks to solve this, and I
> think a hack to make it work cleanly for users is better than supporti
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This still wouldn't put us in a place where existing dumps are
> >> automatically fixed up during import. We'd parse the expressions as
> >> nextval('foo'::text::regclass), which will work but it's effectively
> >> still late-bindin
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > That was my thinking. The issue has probably been there since 7.3. I
> > don't
> > think we need to shove in a solution now, especially when there is so much
> > disagreement about the behavior.
>
> Well, we have a new issue t
Tom Lane wrote:
> Bruce Momjian writes:
> > Hold, I think I see an idea here. We have two cases, those for SERIAL
> > and those for manual nextval() in DEFAULT. For SERIAL, we can easily
> > map to a nextval(::regclass) call on pg_dump reload. For manual
> > nextval, it will appear in the dump
Bruce Momjian writes:
> Tom Lane wrote:
>> This still wouldn't put us in a place where existing dumps are
>> automatically fixed up during import. We'd parse the expressions as
>> nextval('foo'::text::regclass), which will work but it's effectively
>> still late-binding --- the actual constant is
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That was my thinking. The issue has probably been there since 7.3. I don't
> think we need to shove in a solution now, especially when there is so much
> disagreement about the behavior.
Well, we have a new issue that has made the problem much wor
Bruce Momjian writes:
> Hold, I think I see an idea here. We have two cases, those for SERIAL
> and those for manual nextval() in DEFAULT. For SERIAL, we can easily
> map to a nextval(::regclass) call on pg_dump reload. For manual
> nextval, it will appear in the dump as nextval('myseq'::text),
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Sep 28, 2005 at 10:41:12PM -0400, Bruce Momjian wrote:
> >
> > Also, why is the nextval ::text casting output by pg_dump anyway?
>
> AFAICS, pg_dump outputs "serial" (at least in 7.4.7 which is what I
> have to hand) when it
On Wed, Sep 28, 2005 at 10:41:12PM -0400, Bruce Momjian wrote:
>
> Also, why is the nextval ::text casting output by pg_dump anyway?
AFAICS, pg_dump outputs "serial" (at least in 7.4.7 which is what I
have to hand) when it should meaning that dumps restored will get the
new syntax anyway. Or am I
Am Mittwoch, 28. September 2005 18:10 schrieb Bruce Momjian:
> If it was that bad, we should have fixed it during development, not
> during beta. The only reason it is getting attention now is because it
> is triggered more by a new feature we are adding, a feature we can
> easily remove.
That wa
Also, why is the nextval ::text casting output by pg_dump anyway?
---
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should hard-code something in the backend so if the
> > function oid is nextval/currval/setv
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should hard-code something in the backend so if the
> > function oid is nextval/currval/setval, we strip off any text casting
> > internally.
>
> NO. No bloody way ... that is far dirtier than any other proposal
> that's been made in t
Bruce Momjian writes:
> I am thinking we should hard-code something in the backend so if the
> function oid is nextval/currval/setval, we strip off any text casting
> internally.
NO. No bloody way ... that is far dirtier than any other proposal
that's been made in this thread. I don't even want
Just to summarize, I am arguing from a usability perspective, because I
believe the simplest API is one that will last for many releases and not
have to be redesigned, nor require too much adjustment from our users.
---
Bruc
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we need to have nextval('') do early binding and have
> > nextval(''::text) (or some other name) do late binding.
>
> You can't have that in exactly that form, because text is invariably
> the preferred resolution of unknown-type literals,
Bruce Momjian writes:
> I am thinking we need to have nextval('') do early binding and have
> nextval(''::text) (or some other name) do late binding.
You can't have that in exactly that form, because text is invariably
the preferred resolution of unknown-type literals, and we certainly
dare not t
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The more I think about it, the more I think that two sets of function
> >> names might not be such an awful idea. next_value(), curr_value(), and
> >> set_value() seem like they'd work well enough. Then we'd just say that
> >> next
Bruce Momjian writes:
> Tom Lane wrote:
>> The more I think about it, the more I think that two sets of function
>> names might not be such an awful idea. next_value(), curr_value(), and
>> set_value() seem like they'd work well enough. Then we'd just say that
>> nextval and friends are deprecat
Bruce Momjian writes:
> Michael Paesold wrote:
>> Since the NEXT VALUE FOR syntax has a special meaning, would it be better to
>> support the oracle-style syntax sequence.nextval for now (and use the
>> ::regclass for this)? I am not sure how easy that is considering
>> schema.sequence.nextval.
Michael Paesold wrote:
> Tom Lane wrote:
> > However, we could certainly add the NEXT VALUE FOR syntax if that will
> > satisfy your concern about syntax.
>
> Since the NEXT VALUE FOR syntax has a special meaning, would it be better to
> support the oracle-style syntax sequence.nextval for now (a
Tom Lane wrote:
However, we could certainly add the NEXT VALUE FOR syntax if that will
satisfy your concern about syntax.
Since the NEXT VALUE FOR syntax has a special meaning, would it be better to
support the oracle-style syntax sequence.nextval for now (and use the
::regclass for this)? I
Tom Lane wrote:
> Bruce Momjian writes:
> > I still think we shouldn't be hashing this out during beta, but ...
>
> We're looking at ways to fix some bugs. It's never been the case that
> our first-resort response to a bug is "pull out features".
True, but your first guess was that none of this
Tom Lane wrote:
> Bruce Momjian writes:
> > Just to follow up, I agree we can't totally replace all instances of
> > nextval() with regclass because regclass requires a constant string, but
> > I would like to have the regclass behavior with simple syntax and
> > require people who want "late bind
Bruce Momjian writes:
> Just to follow up, I agree we can't totally replace all instances of
> nextval() with regclass because regclass requires a constant string, but
> I would like to have the regclass behavior with simple syntax and
> require people who want "late binding" of the sequence name
Tom Lane wrote:
> > It is
> > only the last one where recommending regclass helps, but is it worth
> > improving sequence/schema renaming by exposing and recommending a
> > ::regclass syntax that will go away as soon as we fix this properly?
>
> Please explain what you think a "proper" fix is. I
Tom Lane wrote:
> Bruce Momjian writes:
> > What I am primarily worried about in your patch is the exposure of
> > ::regclass as a recommended way of doing things. I know we can
> > discourage its us later, but once people start using something, it is
> > hard to change.
>
> Why shouldn't it be
31 matches
Mail list logo
